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Business Systems Planning (BSP) is a 
structured approach to help an organization 
establish an information systems plan that 
can satisfy its near- and long-term informa- 
tion needs. This guide offers assistance to 
BSP study teams by explaining the approach 
and presenting guidelines for conducting a 
BSP study. It can also be used for general 
reference on the subject of planning for 
information systems. 

The guide covers BSP principles, concepts, 
and study overview, then devotes a chapter 
to each of the major activities of a BSP study, 
and includes a final chapter to acquaint the 
reader with follow-on projects. 
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Preface 



Business Systems Planning (BSP) is a structured ap- 
proach to assist a business in establishing an informa- 
tion systems plan to satisfy its near- and long-term 
information needs. The primary purpose of this guide 
is to assist BSP study team members by explaining the 
approach and presenting specific guidelines for con- 
ducting a BSP study. The guide may also be used for 
general reference on the subject of planning for 
information systems. The reader does not need a 
knowledge of computers to understand the concepts 
and to apply the methodology. 

Experience has shown that BSP can be applied to 
all the public sector and all industries in the private 
sector, because the requirements for developing 
information systems are similar regardless of the 
business served or the products and services provided. 
For the sake of simplicity, throughout this manual the 
term business is used for the organization entity being 
studied, regardless of its size or purpose, and whether 
private or public. 

Before initiating a BSP study, the personnel 
involved should consider taking the appropriate 
BSP-related courses. Information on the educational 
offerings is available through local IBM branch offices. 

Because IBM cannot control the manner in which 
this methodology is applied, it takes no responsibility 
for the results. Hundreds of studies have been com- 
pleted successfully using this approach; this guide 
represents as much of that experience as it is feasible to 
include. 

This guide is organized so that readers already 
familiar with BSP can go directly to the material they 
require, while others may progress serially through 



principles, concepts, methodology overview, methodol- 
ogy details, and finally the alternatives and the refer- 
ence material in the appendices. The introduction is 
for those persons who may have heard of BSP but do 
not know its purpose or origin. Chapter 1 presents the 
concepts that form the basis for the methodology, so 
that the reader can understand the basic principles 
without becoming embroiled in the detail of how bsp is 
done. Even persons with some orientation or training 
in the subject may wish to read the introduction and 
Chapter 1 to strengthen their understanding. 

Chapter 2 provides an overview of all the activi- 
ties in a BSP study so that the reader will be prepared 
for the details in the following chapters. 

Chapter 3 deals with getting the proper executive 
commitment before starting a BSP study. 

Chapter 4 discusses the activities that take place 
before the BSP team starts its concentrated study. It 
also outlines the considerations that must be made in 
the management of the study. 

Chapters 5-15 cover the details of the methodolo- 
gy, culminating in the writing of the final report and 
the making of recommendations to the business 
executives. Since each step of the methodology can 
probably be done a number of ways, a single, cohesive 
methodology is outlined and alternatives, where 
appropriate, are included at the end of each chapter or 
in the appendices. For continuity from step to step, all 
examples are based on the same business, a medium- 
size manufacturing firm, except those in the appendic- 
es, which are based on various industries and the 
public sector. 

Chapter 16 gives an introduction to the follow-on 
projects so that an action plan for them may be devel- 
oped during the bsp study. 
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Introduction 



The Changing Environment 

The rapidly changing environment and the constant 
need for businesses to adjust quickly to it make it 
necessary for executive management to have up-to-date 
information available at all times, so that through 
meaningful analyses and resource allocation tradeoffs 
they can manage their businesses more effectively. 
With organization- wide availability of information, 
strategies can be improved, decisions made more 
soundly, and operations performed more efficiently. 

From Operation to Management Control 

Data processing is in transition. Until comparatively 
recently, most businesses considered it a service 
function and used it to support single-operation units 
or locations. In the last two decades applications have 
been developed independently, with very little regard 
for the support they could give other functions and for 
the information they could supply for management 
control. Functional autonomy has been the rule. This 
has resulted in fractionalized and redundant data files 
and in the inaccessibility of data from the many 
operational applications installed in the various 
functions. 

Today, however, businesses are recognizing data 
more and more as a resource that is as important as 
personnel, cash, facilities, or materials. They see the 
need to consolidate the key data files and make 
information available not just to individual functions 
or departments but throughout the business, in order 
for management to gain a business-wide view and be 
able to make multifunctional decisions. 

Many companies have recognized the need for 
company-wide information systems but have been 
unable to develop them for one or more of the follow- 
ing reasons: 

• Failing to obtain executive commitment and 
involvement 

• Establishing objectives and strategies that were not 
in line with their overall business objectives 

• Attempting to implement information systems 
without first understanding the business from 
general management's viewpoint 

• Setting out to implement totally new company-wide 
, information systems rather than a comprehensive 

plan evolving from current systems 

• Failing to put in place 4hose information systems 
management functions required to adequately 
manage the information systems resources 



A Justified Approach 

In an article entitled "Blueprint for MIS," * Dr. Wil- 
liam Zani states, "Traditionally, management informa- 
tion systems have not really been designed at all. They 
have been spun off as by-products while improving 
existing systems within a company. No tool has proved 
so disappointing in use. I trace this disappointment to 
the fact that most management information systems 
have been developed in the "bottom-up" fashion - an 
effective system, under normal conditions, can only be 
born of a carefully planned, rational design that looks 
down from the top, the natural vantage point of the 
managers who will use it." 

In most instances the current operational systems 
have been justified and have been performing effec- 
tively for their specific intent, even though their 
maintenance and interfaces may have become unman- 
ageable. An information system plan should allow a 
modular approach to implementation, providing 
confidence that each module will fit and function 
properly in an integrated network and will interface 
properly with the present operating systems until they 
too can be included in that network. The plan should 
also allow for better decisions concerning the efficient 
and effective commitment of information systems 
development resources. With such a plan, the required 
information can be more readily obtained. 

Business Systems Planning (BSP) is geared to help 
provide such a plan through: 

• A top-down approach to (1) getting people commit- 
ted and involved (starting with top management and 
working down through the organization) and 

(2) studying the business (working from the overall 
to the detail level) 

• A bottom-up approach to implementation 

• Use of a structured methodology proven in hun- 
dreds of studies 

• The translation of business objectives into informa- 
tion requirements 

The effectiveness of the BSP methodology can be 
attributed to two components: 

• The fundamental principles and concepts - the 
unvarying ideas and logic that form the basis for 
BSP, including the standards upon which the proce- 
dures are based 



* Harvard Business Review, November/December, 1970 



• The sequenced activities, techniques, disciplines, 
time, outputs, planning, team composition, etc., 
established to fill a particular organization's need 
and situation (although consistbnt with BSP's basic 
principles and concepts, the procedures are flexible 
and vary with the particular environment) 

Origin of IBM's Business Systems 
Planning Function 

Learning from its own mistakes and those of other 
companies that attempted to implement large informa- 
tion systems in the 1960s, IBM realized that a disci- 
plined approach was required, using proven principles 
and methodologies. In 1966 a business- wide Informa- 
tion Systems Control and Planning Department was 
established at IBM's Data Processing Group headquar- 
ters. The Data Processing Group was a total business 
unit comprising the engineering, manufacturing, 
marketing, and service divisions responsible for all of 
IBM's domestic data processing business. 

Until the Control and Planning Department was 
established, IBM had little overall direction in the 
internal use of computers. In fact, little coordination 
took place between divisions; most data processing 
activities were confined to locations and units within 
divisions. Consequently, each manufacturing plant 
and marketing region developed and operated its own 
system. Although the individual systems carried out 
similar functions, they differed in design and perfor- 
mance; they could not be used interchangeably and 
could not communicate with each other. The result 
was a redundancy of data and excessive use of the data 
processing resources required to develop and maintain 
such systems. Even with this large expenditure of 
resources by each division, the systems were mainly 
satisfying the local department needs of the business, 
rather than doing an overall data processing job. 
When steps were taken to improve the data processing 
within a division (for example, development of a 
consolidated order entry system within the marketing 
division), little serious attention was given to an 
effective interface of that system with inputs from 
engineering and outputs to manufacturing. The 
business was not getting the return on investment from 
data processing that it could have because the informa- 
tion needs of the business, and particularly those of the 
general manager responsible for the business, were not 
being accommodated. 

The first effort of the Control and Planning Depart- 
ment was to inventory and profile the systems existing 
within the business and the plans for the future. At the 
same time, recognizing that the data processing effort 
must be directed toward satisfying business needs and 
not solely toward individual functions and depart- 
ments, the Control and Planning Department estab- 



lished a set of information system strategies covering 
five major areas: 

1. Fixed data responsibility 

2. Single source and parallel distribution of data 

3. Central control and planning of information systems 

4. Organizational independence of data 

5. Resource sharing of data, equipment, and 
communications 

With the knowledge of what was being done with 
data processing, and the direction established through 
the set of strategies, the department defined a network 
of information systems and assigned responsibilities for 
the development of the systems. These systems ad- 
dressed the operational, functional, and general 
management needs for information. 

As the definition and design efforts for the business- 
wide network of information systems got under way in 
the late 1960s, many of IBM's customers showed 
interest in learning how they might better manage their 
information system resources. In an effort to assist 
these interested customers, IBM established the Busi- 
ness Systems Planning (BSP) program in 1970. 

To conduct the program, the nucleus of the control 
and planning department that developed the internal 
information systems plan was transferred to the Data 
Processing Division headquarters. This group proceed- 
ed to document proven methodologies and institute a 
training program to educate regional and branch office 
personnel and customers in the approach. Executive 
briefings and seminars were established to show 
customer executives the potential benefits of the 
approach and the reasons why their involvement was 
vital to successful implementation of information 
systems. 

The methods used in developing this information 
systems plan and the lessons learned have since been 
used by many IBM customers. Application of BSP 
methodology has helped them to formulate their 
information system plans and control mechanisms and 
to improve their use of information and data process- 
ing resources. Studies using the BSP methodology and 
guidelines have been conducted successfully by profit 
and nonprofit organizations, of varying size, in many 
industries. 

Objectives and Potential Benefits of 
BSP 

With a reasonable amount of planning and control, the 
user of this BSP approach should be able to attain its 
objectives and realize its potential benefits. 

Objectives 

The first and most important objective of BSP is to 
provide an information systems plan that supports the 
business's short- and long-term information needs and 



is integral with the business plan. There are other 
objectives that help to justify and clarify the approach: 

1. Provide a formal, objective method for management 
to establish information systems priorities without 
regard to provincial interests. 

2. Provide for the development of systems that have a 
long life, protecting the systems investment, because 
these systems are based upon the business processes 
that are generally unaffected by organizational 

, changes. 

3. Provide that the data processing resources are 
managed for the most efficient and effective support 
of the business goals. 

4. Increase executive confidence that high-return, 
major information systems will be produced. 

5. Improve relationships between the information 
systems department and users by providing for 
systems that are responsive to user requirements and 
priorities. 

6. Identify data as a corporate resource that should be 
planned, managed, and controlled in order to be 
used effectively by everyone. 

The illustration below shows the overall flow of BSP 
and relates the bsp study to the activities that follow. 
This relationship is expanded upon in Chapter 16, with 
an explanation of the follow-on activities. 
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Information architecture 
Architectural priorities 






l/S management 
Action plan 








Follow-on 
projects 


Information architecture 
First system (s) 
l/S management 



Potential Benefits 

Application of the approach and methodology con- 
tained in this planning guide offers many potential 
benefits to three management groups: 
To executive management: 

• An evaluation of the effectiveness of current infor- 
mation systems 

• A defined, logical approach to aid in solving man- 
agement control problems from a business 
perspective 

• An assessment of future information system needs 
based on business-related impacts and priorities 

• A planned approach that will allow an early return 
on the company's information systems investment 

• Information systems that are relatively independent 
of organization structure 

• Confidence that information system direction and 
adequate management attention exist to implement 
the proposed systems 

To functional and operational management: 

• A defined, logical approach to aid in solving man- 
agement control and operational control problems 

• Consistent data to be used and shared by all users 

• Top management involvement to establish organiza- 
tional objectives and direction, as well as agreed- 
upon system priorities 

• Systems that are management and user oriented 
rather than data processing oriented 

To information systems management: 

• Top management communication and awareness 

• Agreed-upon system priorities 

• A better long-range planning base for data process- 
ing resources and funding 

• Personnel better trained and more experienced in 
planning data processing to respond to business 
needs 

The plan that results from a BSP study should not be 
considered unchangeable; it simply represents the best 
thinking at a certain point in time. The real value of 
the BSP approach is that it offers the opportunity to 
(1) create an environment and an initial plan of action 
that can enable a business to react to future changes in 
priorities and direction without radical disruptions in 
systems design, and (2) define an information system 
function to continue the planning process. 



Data management 
l/S planning 



Chapter 1. BSP Concepts 



Business Systems Planning is most often thought of as 
a structured approach or methodology. This meth- 
odology, however, is based upon some fundamental 
concepts, a good understanding of which can give the 
bsp study team members: 

1 . A better appreciation of the "why's" of the 
methodology 

2. Improved confidence in applying variations to meet 
specific situations 

3. A better background with which to communicate 
the objectives and eventual recommendations to 
senior management 

The premise for conducting a BSP study is that there 
exists within the organization a need for significantly 
improved {computer-based information systems (i/S) 
and a need for an overall strategy to attain them. BSP is 
concerned with how these information systems should 
be structured, integrated, and implemented over the 
long term. The basic concepts of bsp can be related to 
the long-term objectives for I/S in an organization. 

An I/S Must Support the Goals and Objectives of the 

Business 

This most basic concept underlies the "top down" 

philosophy of the methodology as well as several of the 

specific steps, such as executive interviews and system 

priorities. 

Since information systems can be an integral part of 
a business and be critical to its overall effectiveness, 
and because they will continue to represent major 
investments of time and money, it is essential that they 
support the organization's true business needs and 
directly influence its objectives, bsp, then, can be 
thought of as a vehicle or process to translate business 
strategy into i/s strategy (see Figure 1). 
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Figure 1. Translation of business strategy to I/S strategy 

Obviously, it is important that an organization be 
willing and able to express its long-term goals and 
objectives. For some organizations, this can be done 
principally through the business plan. For others, 
where a business plan is not available or current, it can 



be done as a part of the bsp methodology. In either 
event, a recognition of this basic need by senior 
management is critical, for only with that recognition 
will their commitment and involvement be great 
enough to guarantee a meaningful bsp study. 

An I/S Strategy Should Address the Needs of AH 
Levels of Management Within the Business 

This requirement has several implications relative to 
I/S structure. First, it is important to recognize the 
varying characteristics of information as needed by 
different activities and management levels. Typically, 
lower levels need considerable detail, volume, and 
frequency, higher levels need summaries, "exception" 
reporting, and inquiries, and still higher levels need 
cross-functional summaries, special requests, "what if 
analyses, "external" requirements, etc. It would be 
impractical to construct a single system to accommo- 
date all activities or management levels, and it would 
be erroneous to associate any one type of information 
requirement solely with one management level. 
Clearly, there is need to establish some reasonable 
framework upon which the i/s can be defined. 

First, the emphasis in I/S should be in support of 
management decision making. This is in contrast to 
more traditional bookkeeping or recordkeeping 
functions. Business decisions are made for various 
purposes, but most can be associated with either 
planning or control. Planning, of course, is the estab- 
lishment of various missions, objectives, and policies, 
and it occurs at all levels. Good information is vital to 
the establishment of good plans. Control decisions, on 
the other hand, are made in order to guide an activity 
toward some implicit or defined (by the plan) objec- 
tive. The l/S can provide the measurements of the 
current or actual condition to the decision maker. We 
thus complete a planning, measurement and control 
cycle with l/S potentially an integral part. Since 
planning and control are the keys to decision making, a 
framework for l/S based upon these activities can be 
utilized. It has been proposed, * and well accepted 
today, that three distinct but concurrent planning and 
control levels exist in any organization: 

Strategic planning, the process of deciding on 
objectives of the organization, on the resources used 
to attain these objectives, and on the policies that 
are to govern the acquisition, use, and disposition of 
resources 

♦Anthony, R.N. Planning and Control Systems: A Frame- 
work for Analysis, Harvard Business School, Division of 
Research, 1965. 



Management control, the process by which managers 
assure that resources are obtained and used effi- 
ciently in the accomplishment of the organization's 
objectives 

Operational control, the process of assuring that 
specific tasks are carried out effectively and 
efficiently 

Further characteristics of these areas are outlined in 
Figure 2. An advantage of this framework is that it 
does not restrict planning and control activity to any 
particular industry, function, or management level. A 
conclusion at this point is that an i/S could convenient- 
ly address itself to any one of the above three planning 
and control levels. 

Resource management is also key to this philosophy 
and represents a major vehicle for I/S definition. The 
specific resources to be managed vary in nature and 
relative importance from one organization to the next. 
Examples of traditional resources to be managed are 
people, facilities, materials and money. Their require- 
ments are based upon the needs to support the prime 
mission area of the organization, e.g., its products or 
services. Because an organization's product or service 
area has all the attributes of a resource, i.e., a life cycle 
of activities and decision points, and yet drives the 
other resources, it is referred to as the "key resource." 
Each resource, including the key resource, is managed 
through planning and control decisions of the three 
levels previously discussed. Resource management has 
the desired characteristic of cutting across organiza- 
tional boundaries - vertically across management 
levels and horizontally across functional lines. Thus a 
framework based on resources as well as planning and 
control levels can be established, and an i/s architec- 
ture can be applied within this framework. 



An I/S Should Provide Consistency of Information 
Throughout the Organization 

The keyword in this objective is consistency. The 
implication is that information derived from more 
traditional data processing applications is not necessar- 
ily consistent, particularly when applied to new 
business problems (decision areas) of broader scope. 
The problems in data consistency normally arise as a 
result of a historical evolution of computer usage that 
traditionally occurs. Isolated and independent applica- 
tion areas are selected and mechanized, typically to 
reduce operational costs. The data files are defined as 
necessary to support the specific needs of each applica- 
tion without regard to one another or to future applica- 
tions. The data itself is converted from manual files 
located and maintained by the using organization. 

As computer applications are added, new data files 
are usually required since the data requirements for 
different applications are rarely the same. These are 
usually created from spinoffs of existing mechanized 
files plus any additional data that may be required 
from the using area. Summary-type reports for higher 
management levels are the result of sorting and merg- 
ing various existing data files together to create new 
ones. Rarely is any existing data file of the form or 
content required to provide newly requested informa- 
tion of any magnitude. Thus new data files are born. 
Data redundancies and file update requirements 
multiply. The continual cry from management that "I 
know the data that I need is somewhere in data proc- 
essing, but I can't get at it" may be basically true from 
their point of view. The data may be there, but not 
necessarily defined as needed, of adequate summary 
level or sequence, or of proper time period or currency. 



Decision 
Characteristic 


Planning and Control Level 


Strategic 
Planning 


Management 
Control 


Operational 
Control 


Management 
involvement 


General management 
Functional management 


General management 
Functional management 
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Figure 2. Characteristics of planning and control levels 



Data, then, exists in most organizations in varying 
form, definition, and time. The form may be uncaptured 
raw data, mechanized data files, detailed DP reports, 
summarized DP reports, business documents, or 
knowledge in someone's head. The definition of any 
given data can have as many variations, and thus 
inconsistencies, as there are users of that data. For 
example, "salary" to the payroll department may mean 
an employee's actual monthly pay, to the project 
manager an annual figure plus burden to be charged to 
a customer, to the department manager a budget line 
item representing total expense for all reporting 
employees. In addition, a time inconsistency is very 
likely to exist between what may otherwise be compa- 
rable data. Data may be captured by such varying 
methods as the mail, telephone, data terminals, or 
satellites. It may be "batched" over varying lengths of 
time by the user or by DP before processing, or it may 
be entered "online" as each transactiori occurs, directly 
from its source. Data may be processed daily, weekly, 
or monthly on a predetermined schedule, or it may be 
incapable of being processed until a series of prior 
computer runs are completed (e.g., the month-end 
closing). The output itself may be mailed or it could be 
immediately available as the result of an online 
inquiry. Finally, the report may be up to the second, as 
when reading from a terminal, or it may have lain in a 
desk for three weeks after last month's processing. The 
combinations of time deviations between data capture, 
data processing activity, and actual data usage are 
many. 

With all these potential data inconsistencies, it is no 
wonder that reports frequently don't "match" between 
using departments and managers. This becomes a 
problem most often during interdepartmental decision- 
making or at higher reporting levels where consolida- 
tion of multifunction activities is important. Attempts 
to provide better data consistency usually result in 
"resystematizing" or "consolidating" existing applica- 
tions into larger ones with broader problem scope and 
data definitions. This may yield a satisfactory system 
within the defined scope, but again, as still broader 
problems are addressed, there will undoubtedly be data 
inconsistencies between the larger systems. Resystem- 
atizing at this scope may be extremely expensive and 
difficult to justify, let alone accomplish. Comments 
prevail such as "our systems cannot talk to one 
another." 

What has been described is the classical "bottom 
up" evolution of data processing systems. In order to 
begin to address the data consistency problem, a 
different philosophy must be adopted relative to data 
management. This is commonly referred to as 
managing data as a resource. This concept suggests that 
data is of considerable overall value to an organization 



and should be managed accordingly. It should be 
potentially available to and shared by the total business 
unit on a consistent basis. It should not be controlled 
by a limited organizational segment but by a central 
coordinator, much like other corporate resources, such 
as cash and personnel. The management function 
would include formulating policies and procedures for 
consistent definition, sourcing, technical implementa- 
tion, use, and security of the data. 

An I/S Should Be Able to Live Through Organization- 
al and Management Change 

Many data processing systems and applications are set 
up to provide the information needs of a specific 
department or other organizational entity. Others are 
built solely on the specific output report requirements 
of a particular manager. Both types can become 
immediately obsolete upon a reoganization or manage- 
ment change. A new manager may have his own ideas 
as to what information is needed to run the depart- 
ment. While this kind of change is inevitable, it can be 
expensive from a data processing standpoint. The data 
processing system, however, should in no way inhibit 
management flexibility in a dynamic enterprise. Thus, 
the I/S must anticipate and be capable of living through 
the long-term organizational and management changes 
of a business with minimum impact if the expected 
return on investments is to be realized. 

This objective cannot be realized without the proper 
support vehicle for I/S, and this vehicle must be 
independent of the various components of the organi- 
zational structure. The bsp vehicle is the business 
process, that is, a basic activity and decision area 
irrespective of any reporting hierarchy or specific 
management responsibility. A logical set of these 
processes can be defined for any type of business and 
will undergo minimum change as long as the product 
or service area of the business remains basically the 
same. 

One example of a business process is purchasing. A 
particular business might define this as "the process by 
which raw materials are acquired from vendors." There 
may or may not be a separate organizational unit to 
accomplish this process, or indeed there may be 
several. Inherent within this process are the various 
activities and decisions necessary to accomplish the 
process. 

Defining the organization's business processes is one 
of the most important parts of the BSP methodology, 
and the method for doing so is tied directly to the 
previously discussed I/S framework, that is, one based 
on resources and planning and control levels. With 
this in mind it is convenient to define an organization's 
business processes in association with each of its 
defined resources. Emphasis in BSP is normally placed 



upon those processes necessary to manage the key 
resource. Each resource of a business can be thought of 
as having a "life cycle" made up of several stages. A 
product life cycle, for example, has four stages: re- 
quirements, acquisition, stewardship, and retirement. 
The time spread of the life cycle can vary greatly with 
the particular product area but is of no consequence in 
this approach. Business processes can be identified to 
describe the major activities performed and decisions 
made by the business in the course of managing the 
resource throughout its life cycle. These can normally 
be organized into a process hierarchy, and this is done 
without regard to organizational involvement or 
responsibility. 

The above approach results in process definitions 
that encompass the three planning and control levels 
previously discussed - namely, strategic planning, 
management control, and operational control. Using a 
product resource as the example again, the decision to 
pursue a particular product area would be "strategic 
planning," the planning and control decisions relative 
to product volumes or advertising expenditures would 
be "management control," and the decisions in areas of 
engineering control, manufacturing efficiency, etc., 
would be "operational control." By using this approach 
for all the resources it is possible to define all the 
business processes that take place within any organiza- 
tional segment. This may be tempered by practicality 
in the actual bsp as there may be little i/s support 
interest for some of the resources. 
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The I/S Strategy Should Be Implemented By Subsys- 
tem Within a Total Information Architecture 

There are several implications and concepts associated 
with this statement. The first is that a total I/S to 
support the entire business unit's needs is too big to 
build in any single project. However, because of the 
many problems associated with a "bottom up" evolu- 
tion of systems (data inconsistencies, non-integrated 
system designs, expensive resystematizing, priority 
difficulties, etc.), it is very important that long-range 
goals and objectives for I/S be established. The basic 
concept, then, is top-down I/S planning with bottom-up 
implementation (Figure 3). 

With this concept the long-range I/S goals and 
objectives are identified through a top-down planning 
process (the BSP approach). The identified systems 
are then implemented in a modular building-block 
fashion over time while remaining consistent with the 
organization's business priorities, available funds, and 
other shorter-term considerations. This philosophy can 
be likened to the detail design and construction of a 
large office building, which would be unthinkable 
without an architect's approved drawing of the finished 
product. 



The BSP methodology, although consisting of 
considerably more steps and detail than shown in 
Figure 4, is consistent with this philosophy. Step 1 of 
Figure 4, defining the business objectives, is intended 
to ensure agreement among all executive levels as to 
where the business is going, so that the i/s strategy can 
be in direct support. Step 2, defining the business 
processes, establishes the prime long-term basis for l/s 
support in the business. Step 3, defining the data 
classes, can be done on the basis of the processes to be 
supported. A data class, as the name implies, is a 
major category of data needed to support one or more 
business processes. For example, customer informa- 
tion is a data class needed in several process areas, such 
as order entry, billing, and distribution. This step 
results in a definition of all the data to be managed as^ 
resource across the business unit. Step 4, defining the 
information architecture, becomes a statement of the 
long-term l/S objective. This is normally in the form of 
a group of interrelated I/S areas and the associated data 
to be managed. From the information architecture the 
individual modules can be identified, prioritized, and 
built as scheduled by the l/S plan. 
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Figure 4. General I/S planning approach 

A significant piece of the bsp methodology is the 
formulation of a recommended information architec- 
ture. The intent is to develop an implementation 
strategy that can be built in modules and yet provide 
justifiable return to the business at each step. These 
modules or implementable pieces are generally referred 
to as information systems (i/S). Each could be thought 
of as the depository or management point for a particu- 
lar set of the data classes. As the data classes are 
implemented (assumed through data base technology), 
it is possible to provide the information needs for 
various business processes. Each i/s then normally 
becomes associated with one or more business process- 
es and one or more data classes (see Figure 5). The 
implementation strategy should obviously be in tune 
with the business needs. An identified i/s is responsi- 
ble for the collection and maintenance of its data bases 
for the entire business. Other, or later implemented, 



systems can draw on these data bases as well as new 
ones that they will create and maintain. 

Most of the identified i/S areas will normally be in 
support of processes that are operational in nature. 
That is, the decision areas inherent in the processes will 
relate to the "operational control" level of planning 
and control. Thus these I/S's are sometimes referred to 
as operational control systems. The managed data is 
also at an operational level and is typified by much 
detail and quantity. A management control system, on 
the other hand (Figure 5), is in support of a 
"management control" category of processes. Its 
managed data would typically be summarizations of 
the internally generated operational data (dotted lines 
in the figure) plus any other data (competitive data, for 
example) as necessary tosupport the processes. By 
having "business plan" data in the data base, the 
executive could effect control decisions by comparing 
actual versus plan for his area of responsibility. 

In summary, there are a number of basic concepts 
and philosophies relative to information systems upon 
which the bsp methodology is based. The methodology 
itself should be considered flexible in nature. That is, 
certain steps and techniques could be altered in order 
to adapt to specific situations without detriment to the 
final outcome. However, these basic concepts them- 
selves should be considered inviolate. They, in effect, 
are BSP. 
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Chapter 2. Overview of the BSP Study Approach 



The keys to success in planning, developing, and 
implementing an information architecture that effec- 
tively supports the business goals are: 

• Top-down planning with bottom-up implementation 

• Managing data as a corporate resource 

• Orientation around business processes 

• Use of a proven, comprehensive methodology 
Chapter 1 examined the first three at some length. 

This chapter gives an overview of a proven methodolo- 
gy for the BSP study which will be delineated in more 
detail in the following chapters. 

Perspective 

Since BSP is part of an overall cycle for providing the 
business with required information, it should be put 
into perspective. As Figure 6 shows, there is a major 
juncture between identification of overall business 
requirements and the six project phases for implement- 
ing an i/s. Requirements are identified for a total 
business unit and then separated into projects that are 



undertaken and implemented over time. In addition to 
information systems projects, there is also a continuing 
set of projects covering information architecture and 
information systems management (ISM). Identification 
of overall business requirements is not reiterative 
unless a major change occurs within the business unit 
that would change the basic business processes. 

BSP is a methodology for identifying the business 
requirements. If an entire business were not included 
in the BSP study, but only a component such as one 
profit center, additional BSP studies would be appropri- 
ate for other business components. 

In the past, and in many businesses today, projects 
are defined to address a functional area of the business 
without regard to the total requirements of the business 
unit. BSP can provide overall direction for the total 
business before projects are undertaken and therefore 
avoid the fractionalization of data and inconsistencies 
of systems. 
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The top-down, bottom-up aspects of the bsp study 
are reflected in the following: 
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The study progresses from the very broad world in 
which the business exists down to the data required to 
run the business. The data is categorized into data 
classes that lead to the definition of information 
systems to support the business processes and business 
objectives. The study starts with a collection of facts 
about the business that are usually available in docu- 
mented form throughout the organization. These facts 
are organized, abstracted, and analyzed by the study 
team and enhanced by the top executive, who explains 
the business and adds those points usually not docu- 
mented. The study progresses to an identification of 
the major activities and decision processes in the 
business and then each of the executives is asked to 
validate and enlarge upon the facts that have been 
gathered and analyzed. The analysis ends with the 
consolidation and comparison of the facts from all 
sources. From this understanding the study follows the 
normal path of findings and conclusions, recommenda- 
tions, action plan, and executive presentation for 
concurrence and support. 

Major Activities 

As Figure 7 indicates, there are two major activities 
that precede a bsp study and eleven in the study itself. 
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While these activities may be carried out in varying 
degrees, none can be omitted. Figure 7 shows these 
activities and their most logical arrangement. When 
one becomes fairly familiar with the bsp approach, 
however, he can, as appropriate, do part of a given 
activity and delay the balance. The remainder of this 
chapter is a brief commentary on these major activities. 

Gaining Commitment 

A bsp study should not be started unless a top execu- 
tive sponsor and some other executives are committed 
to being involved in it. The study must reflect their 
view of the business, and the success of the study 
depends upon their providing the business understand- 
ing and information requirements to the team. Most of 
the input will come directly or indirectly from these 
executives. 

Since approval of study recommendations commits 
the company for several years to a certain direction in 
the use of its data processing resources, it is important 
at the outset to get agreement on the scope and objec- 
tives of the study and on its expected deliverables, so as 
to minimize future misunderstandings. 

The most important action following commitment 
regards selection of the team leader, an executive who 
will work full time in the study and direct team activi- 
ties. He sees that contact with other executives is on 
the proper level and that input from them is interpreted 
correctly. A letter from the sponsor to all participating 
executives sets the tone and signifies commitment. 

Preparing for the Study 

Considerable saving of time, avoidance of frustation, 
and higher quality of output can be gained by proper 
study preparation. All executive participants and the 
team need to know what will be done, why, and what is 
expected of them. Proper education and orientation 
will provide the best input from the executives and the 
best use of it by the team. 

Interviewees are selected as soon as possible so as to 
allow for their orientation, scheduling of interviews, 
and the providing of information to the study team. 
For maximum efficiency on the part of the team in 
working together full time during the study, informa- 
tion on the company and on data processing support is 
gathered before the study kickoff. 

A control room is established so that the team may 
work together, display relevant material on the walls, 
and conduct interviews. 

The major output should be a study control book 
containing: a study work plan; a schedule of interviews 
and a schedule of checkpoint reviews with the sponsor; 
an outline of the final report from the BSP study; and 
business and information systems data, analyzed and 



charted, and ready for the kickoff period. This activity 
should end with a review by the bsp study sponsor. 

Conducting the Kickoff Meeting 

The bsp study itself and the full-time participation of 
the team members starts with the kickoff meeting, 
which consists of three presentations. First, the 
executive sponsor reiterates the objectives, expected 
outputs, and perspective of the study with relation to 
other company activities and objectives. 

The next presentation is concerned with the main 
purpose of the kickoff, which is to provide that each 
team member is conversant with the information that 
has been gathered and to discuss those facts that are 
not part of the information supplied. To accomplish 
this the team leader "walks through" the business facts 
that have been gathered and makes subjective com- 
ments and additions on facts that cannot be readily 
documented - politics and sensitive issues, and changes 
planned and in process. He should also cover the 
decision process, how the organization functions, key 
people, major problems, the user's view of DP support, 
and the image of the DP department. 

The third presentation is made by the information 
systems director or one of his managers, who gives the 
team a view of data processing analogous to what was 
presented for the business. He should also cover 
project status and project control, history of major data 
processing projects started in the last two years, major 
current activities, planned changes, and major 
problems. 

These three presentations, added to the facts that 
have been gathered and made readily available to the 
team, should give the team an overall understanding of 
the business and the present and planned data process- 
ing support. 

Defining Business Processes 

No other activity during the study can be quite as 
overwhelming or as important as the identifying of the 
business processes. Since these processes form the 
basis for executive interviews, the information architec- 
ture, problem analysis, data class identification, and 
various follow-on activities, everyone on the team must 
acquire an understanding of all the processes, and they 
can do so by assisting full time in their identification 
and in the writing of their descriptions. The major 
output from this step will be a list of all the processes, a 
description of each, and the identification of those that 
are key to the success of the business. 

Defining Data Classes 

The defining of data classes is the grouping of data into 
logically related categories. This classification, and its 
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subsequent modification during the follow-on projects, 
helps the business develop data bases over time with a 
minimum of redundancy and in a manner that allows 
systems to be added without a major revision to the 
data bases. Since data must be recognized as a corpo- 
rate resource, it deserves the attention recommended 
here. 

When the data classes have been identified, they are 
related to the business processes in order to define the 
information architecture, and they are related to 
present files to assist in the development of a migration 
plan. 

Analyzing Business/ Systems Relationships 

The main purpose of this activity is to show how data 
processing currently supports the business in order to 
develop recommendations for future action. The 
currently existing organizations, business processes, 
information systems (applications), and data files are 
analyzed to identify voids and redundancies, help 
clarify responsibilities, and further the understanding 
of the business processes. 

The main analysis tool is the matrix, and various 
matrices are developed using combinations of the four 
elements. The key matrix for the executive interviews 
is the organization/process matrix, and its intercepts 
denote the decision makers, major and minor organiza- 
tional responsibility for a process, and current data 
processing support. 

This activity will not only prepare the team for 
discussion with executives but will also help them 
determine requirements for information support. 

Determining the Executive Perspective 

This activity is an integral part of the top-down 
approach. Its purpose is to validate the work done by 
the team, determine the objectives, problems, and 
information needs and their value, and gain executive 
rapport and involvement. The executive interviews 
provide the business understanding necessary for 
information systems planning. 

The major output consists of notes from the inter- 
views, an update of the control room charts, and a new 
or improved rapport between the executive and the BSP 
study team. 

Assessing Business Problems 

Some of the business problems were supplied as input 
during the fact-gathering step. These were expanded 
upon and complemented by the knowledge of the team 
and finally validated, explained, and added to in the 
executive interview. The problems must now be 
analyzed and related to the business processes so as to 
give guidance to the setting of project priorities and to 



show clearly that better information will help to solve 
the problems. 

One of the last activities in assessing the business 
problems is to divide them into those which are 
information systems support problems and those which 
are non i/s problems. The non I/S problems will be 
delineated and given to the executive sponsor to follow 
up on while the information systems support problems 
continue to be addressed in the BSP study and by the 
follow-on activities. 

Defining Information Architecture 

This activity represents a major movement from an 
examination of the present to a synthesis of the future. 
It is here that we sketch future information systems and 
their accompanying data. 

Systems may be viewed as the automated portions of 
processes. Data bases are the computerized part of the 
total inventory of data in the business. Information 
architecture brings order and structure to the systems 
and the data they create and use. Once it is structured, 
it allows for step-by-step development to migrate from 
the applications of today to the information systems of 
the future. 

Because this task involves drawing a blueprint for 
the future, it deserves the attention of the whole team. 

Determining Architectural Priorities 

Since a total information architecture cannot be 
developed and implemented at one time, the team must 
establish priorities for the development of the systems 
and data bases. By deciding which of the data bases 
should be designed and implemented first, the team 
establishes which subsystems will be defined during the 
follow-on project. This allows an early implementation 
for a "pay-as-you-go" foundation and helps establish 
credibility for the balance of the output from the BSP 
study. 

Prioritization is accomplished by developing a list of 
projects from the subsystems of the information 
architecture, then establishing a set of criteria and 
rating the prospective projects against them. The 
analysis of the business problems is a major contributor 
to this process. 

Reviewing Information Systems Management 
(ISM) 

The purpose of ISM is to eventually establish a con- 
trolled environment in which the information architec- 
ture can be developed, implemented, and operated 
efficiently and effectively. The information systems 
functions are examined during the BSP study to identify 
(1) any changes that could be made immediately to 
enhance success in the follow-on projects, (2) changes 
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that are necessary to properly manage and implement 
the high-priority information architecture projects, and 
(3) major activities that will become projects in the 
follow-on to the bsp study. Fulfillment of this step is 
vital to the successful support of the business by the 
data processing function. 

The major inputs are the information systems 
support problems from the executive interviews, the 
ISM problems as identified by the I/S director, and the 
technologies and skill requirements of the first system 
or systems. Additions and/or changes to the present 
information systems functions that are required for 
planning, developing, and implementing are then 
identified and put in priority sequence. This forms the 
basis for the development of an action plan for ISM 
which feeds into the action plan and report from the 
bsp study. 

Developing Recommendations and Action Plan 

The purpose of the action plan is to assist management 
in its decisions regarding the recommended follow-on 
projects. The follow-on projects will come from the 
architectural priorities and from the information 
systems management recommendations. Each of the 
projects will have been defined as a result of the 
activities in those two areas. The action plan brings 
these together to identify specific resources, schedules, 
and interactions of the projects. 

Another major part of the action plan should be the 
identification of the steps preparatory to starting each 
of the follow-on activities. These must be examined 



and sized before start dates can be put on the follow-on 
projects, so that management can give the direction 
necessary to move immediately into those preparatory 
activities. 

Reporting Results 

The purpose of the final report and executive presenta- 
tion is to obtain executive management commitment 
and involvement for implementing recommendations 
from the BSP study. The format of the report was 
agreed upon before the study was started, but may 
have to be modified slightly now, on the basis of the 
study results. Various parts of the report should be 
written during the bsp study and finalized at this time. 
The report should be prepared as follows: 

1 . It should include an executive summary. 

2. The supporting detail, such as descriptions of the 
business processes, should be contained in 
appendices. 

3. It should be possible to extract highly confidential or 
sensitive material easily and still have the balance of 
the report usable by all people participating in the 
follow-on activities. 

The report provides the basis for the executive 
presentation and the distribution of the final results to 
those people designated by the sponsor. After the 
executive presentation, which is normally given by the 
team leader, all other relevant material that is not a 
part of the report should be indexed and filed for ready 
availability in follow-on projects. 
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Chapter 3. Gaining the Commitment 

The success of a Business Systems Planning study 
depends heavily upon the commitment of the business 
to complete all the relevant activities and heed the 
recommendations of the study team. The steps de- 
scribed in this chapter should be completed and an 
assessment made of the commitment of all participants, 
before the final decision is made to move into the 
resource dependent activities. Certain situations and 
environments will be considered unsuitable for a BSP 
study at this stage. If such is the case, the team should 
be prepared to postpone bsp until the situation be- 
comes more suitable. 

In some organizations there may be a problem in 
obtaining access to executive management to explain 
the objectives and expected results of a bsp study. If 
so, the following actions should be considered: 

• Arrange an executive visit to another business that 
has successfully completed a BSP study 

• Invite a senior IBM executive to discuss information 
systems planning with the appropriate executive in 
your organization 

• Conduct an executive briefing session specifically 
for your executives 

• Conduct an executive planning session - a service 
offered by IBM 



• Invite the executive to an executive information 
session conducted at an IBM Customer Executive 
Education center 
The IBM representative can help set up any of these 

activities. 

Establishing the Study Scope 

Normally the executive sponsoring the study (called 
the executive sponsor) will select the scope of the 
organization to be studied. This business unit must be 
defined so that all participants can recognize the 
boundaries within which their activities will be 
concentrated. 

In general, the selected segment should extend to the 
upper levels of the organization, include more than one 
major function, and be of significant importance to the 
organization in that it contributes a major portion of 
the revenues, profits and/or services. 

Businesses whose activities are participated in by 
multiple functional units tend to gain more from a BSP 
study than those that are more simply structured. 

Most companies performing a BSP study choose a 
major operating division, a group of divisions, or the 
entire organization (see Figure 8, options 1-3 respec- 
tively). In each case it should be possible to define 
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Figure 8. BSP organizational business unit options 



15 



boundaries for the study scope, including the measure- 
ments for assessing effectiveness. 

Setting Study Objectives 

Study objectives should now be defined. Good objec- 
tives will be capable of being stated clearly and con- 
cisely. They will have criteria that can be applied to 
measure the degree to which they have been met. In 
addition, they will be applicable to the specific require- 
ments of the organization to be studied. Finally, they 
will be capable of being satisfied by the BSP study team 
working within the defined study scope. 

Specifically, a study team's objectives may be to: 

• Provide a formal, objective method for management 
to establish information systems priorities without 
regard for provincial interests 

• Provide for the development of information systems 
that have a long life, protecting the systems 
investment 

• Provide that the data processing resources are 
managed for the most efficient and effective support 
of the business goals 

• Increase executive confidence that high-return 
information systems will be produced 

• Improve relationship between the information 
systems department and the users by providing 
systems responsive to the users' requirements and 
priorities 

• Identify data as a corporate resource that should be 
planned, managed, and controlled, in order to be 
used effectively by everyone 

Developing Business Reasons for the 
Study 

There are several factors that may make a given 
business more difficult to do a BSP study for than 
others: 

• Major reorganization or transformation of control 
taking place 

• Geographical diversity, necessitating significant 
travel time 

• Well over 20 executives who must be interviewed 

• Multiple independent sub-organizations with 
autonomous decision making processes and with 
unique lines of products/services serving diverse 
markets 

These factors should be reflected in a brief report 
(two or three pages) containing: 

• Statement of the study scope 

• Study objectives 

• Positive contributions of a BSP study 

• Obstacles to successful completion 

• Recommendation either to proceed with BSP or 
postpone it 



Current participants should present this report to an 
executive of the organization and gain agreement on all 
issues. Assuming that the report recommends proceed- 
ing with BSP, the meeting should result in a commit- 
ment to: 

• Appoint a study team leader 

• Resource the study team as appropriate 

• Have open communication of future plans and 
current data among all team members 

• Write a study announcement letter to executives of 
the organization of the form shown in Appendix A. 

Resourcing the Study Team 

Characteristics 

Since the study team is responsible for determining the 
information needs of the entire business and recom- 
mending the nature of its data processing operations 
for years to come, the selection of team members is 
very important. 

The people chosen should: 

• Have several years' experience within the organiza- 
tion, a sound knowledge of their own area, and an 
appreciation of the rest of the business 

• Be able to understand and deal analytically with 
problems 

• Be willing to commit to conclusions and recommen- 
dations that will have a far-reaching effect on the 
organization 

• Be perceived by other management within the 
organization as competent and responsible business- 
men whose opinions will carry considerable weight 
In short, the best people for the study team are those 

who are already in high demand and difficult to make 
available. 

Organization and Responsibilities 

A possible organization structure for the study team is 
depicted by Figure 9. While minor variations are 
possible, the following fundamental responsibilities 
need to be assigned: 

• Executive Sponsor 

- Visibly endorse and support the study effort. 

- Review progress and findings during the study. 

- Receive the final report and make the approval 
decision. 

• Team Leader 

- See that the study is successfully completed. 

- Provide overall direction, make key business 
judgments, and act as liaison with other execu- 
tives of the organization. 

- Direct the study effort on a day-to-day basis and 
organize all necessary administration for the 
team. 
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Team Members 

- Participate in at least some, if not all, interviews. 

- Analyze the data collected and executive perspec- 
tives expressed during the study. 

- Draw conclusions and perform report writing 
tasks. 

Team Secretary 

- Do typing, filing and general secretarial services. 
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Sample study team organization 
Figure 9. Sample study team organization 

Considerations for Full-Time or Part-Time 
Study 

To compound the problem of team selection, a BSP 
study is intensive in nature, and is best performed on a 
full-time basis. While part-time studies may appear to 
be easier to resource and may be successful, they are 
often characterized by deadline and continuity prob- 
lems. Before embarking on a part-time study, assur- 
ance should be gained that: 

• The team will be very well managed. That is, the 
time, effort and skills required to tightly control the 
work schedule must be available and committed. 

• Momentum will not be lost as a result of inactivity 
during the study. 

• Astute use will be made of the administrative 
support available to effectively utilize the time when 
the team is not in session to prepare and type drafts, 
update charts, etc. One full-time member may be 
helpful. 



Manpower Requirements 

If the intent and methodology of BSP are reasonably 
followed, and the study team is full time, the resources 
required should fall within the following limits: 

• Number of team members 4-7 

• Number of weeks 6-8 

These wide variations can be explained by signifi- 
cant variations in organizational types and sizes, as 
well as study objectives. 

Selection of Team Leader 

The success of the study depends largely on the person 
selected by the executive sponsor to lead the team. The 
team leader will be knowledgeable in business matters 
and have a broad perspective of the business. With 
first-hand knowledge of how the various departments 
of the business interact, and where detailed informa- 
tion about the operation of the business can be ob- 
tained, the leader can save the team valuable time. 
Activities of the team leader include: 

• Conducting the study team orientation session 

• Conducting a kickoff meeting for team members at 
the outset of the formal activities of the BSP study 

• Setting and confirming executive session schedules 

• Managing the logistics of the study, including 
day-to-day administration 

• Providing guidance and business perspective 

• Providing resource material 

• Maintaining the schedule 

• Presenting the study report to management at the 
completion of the study 

Sponsor's Letter 

The team leader is now in a position to compose a 
study announcement letter to be signed by the chief 
executive officer and distributed to the executives who 
control the major functions within the scope of the 
study. The letters should cover: 

• Objectives of the program 

• Potential value to the organization 

• Need for functional executives to be involved 

• Need for candor and cooperation of executives 
A sample announcement letter is included in 

Appendix A. 
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Chapter 4. Preparing for the Study 



Using the criteria established in Chapter 3, potential 
team members are identified. Final selection is nor- 
mally performed by the team leader and the executive 
sponsor. The information systems representative on 
the study team will provide continuity for the activities 
that will follow the bsp study. Each team member 
must be thoroughly briefed on the magnitude and 
importance of the study and on the executive sponsor 
commitment to BSP. 

A preparation plan will be prepared by the team 
leader with assistance from IBM personnel. The major 
tasks are: 

• Briefing the study team 

• Gathering data on the business and information 
systems 

• Educating team members 

• Developing the study work plan 

• Defining the study report and ancillary output 

• Creating an executive interview list and schedule 

• Briefing participating executives 

• Obtaining a suitable control room 

• Arranging for administrative support 

• Reviewing with executive sponsor 

These tasks, many of which can be performed 
concurrently, are described in the remainder of this 
chapter. 

Briefing the Study Team 

The team leader, assisted by experienced IBM people, 
should hold a half- to full-day orientation session to 
brief the study team on such topics as: 

• Overview of BSP. This can include development of 
the BSP concept, study methods used, output that 
may be expected, and references to results obtained 
in other BSP studies. 

• Review of activities to date. The team leader 
presents the scope of the study, states its objectives, 
and leads a discussion of the business reasons for 
conducting the BSP studies at this time. 

• Study preparation plan and schedule. Generally the 
team leader will have prepared a draft plan and 
schedule. After this has been presented, the team, 
operating as a working committee, should critically 
review the plan. 

The leader should also discuss with team members 
the allocation of the preparation activities. As a work 
group, the team should divide the activities among 
themselves. In general, distribution of the workload 
among the various team members depends on how 
much time they can devote and how closely the tasks 
relate to their respective functions. 



Gathering Data 

To provide a basis of information the team should 
establish a reference library of both business and 
information systems documentation. Data of value 
will be of two types: 



General Business 

• Environment 

External - economic, customers, technology, 
competition, government, suppliers 
Internal - corporate policies, practices, constraints 
Industry position and industry trends 
Planning process and calendar 
Business plan - goals, objectives, strategy, resources, 
schedules, financial 

Organization charts - position, names, numbers of 
people, and expected changes 
Key decision makers 

Major business measurements and control 
Major studies, task forces, committees during the 
previous three years 
Major problem areas 
Products and markets 
Geographic distribution 
Financial statistics ■ . e 

Sizing statistics (vendors, employees, orders, cus- 
tomers, shipments, purchase orders, etc.) 
Project initiation and funding process 

Information Systems 

i/s plan - goals, objectives, strategies, resources, 

schedules, finances 

Policies and practices 

Organization charts 

Planning process 

Major studies, task forces, committees during 

previous three years 

Geographical distribution (equipment, terminals, 

communication facilities) 

Software environment 

Project initiation and funding process 

Systems j ustification requirements 

Standards/guidelines 

History of major projects started in the last two 

years 

Present and planned systems and data bases 

Major information systems problems 

Sizing statistics (number of programs, jobs per 

period, users, files, data elements, and turnover) 
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Educating the Team 

To enable a smooth, coordinated entry to the bsp 
study, the team members should understand the 
principles of the bsp methodology. Some understand- 
ing of the method of implementation, plus a review of 
the nature of the output that can be expected, will also 
be of advantage to the team members. 

The team leader, working with IBM personnel, 
should establish an education plan for the team. 
Formal IBM education is Available and the local IBM 
office can supply details. 

It is recommended that all team members should 
attendihe same education session. 

Developing the Study Work Plan 

Intensive study activity requires appropriate planning 
and assignment of tasks. A work plan will document 
all the known tasks and indicate major resource - 
allocation required to complete the study. The team, 
working under the guidance of the team leader, should 
develop a study work plan in keeping with the scope 
and objectives previously established. 

There are some study control points that should be 
scheduled in the work plan (e.g., see Figure 10). The 
team should consider whether additional control points 
should be established in each particular study. 

When the activity and project control checkpoints 
have been establishe^,4hey should be combined into a 
single action plan. This plan can be represented on a 



Gantt chart similar to that shown in Figure 1 1. This 
plan is developed under the control of the team leader, 
and agreed upon by the team members. 
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Figure 10. BSP study control points 
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*Preparation time is variable and not full time. 
**Time varies from 6 to 12 days for 10 to 20 interviews 
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Figure 1 1. Work plan for the BSP study 
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Establishing a BSP Study Control File 

The control file should be established to contain all 
material pertaining to the study. Because of the nature 
and number of the documents involved, they should be 
stored in a lockable filing cabinet. Suggested contents 
include: 

Key correspondence 

Statements of objectives and scope 

Project plan 

Schedules 

Data gathered during preparation 

Documentation of completed analyses 

Executive interview notes 

Executive interview summaries 

Project control review meeting notes 

Recommendations 

Report and presentation 

Defining the Structure of the Final 
Study Report and Ancillary Output 

The outline (and table of contents) should be estab- 
lished as early as possible. Team members should be 
assigned specific responsibility for sections of the 
report. During the study period, it is the assigned 
member's duty to coordinate and deliver their section. 

A typical Study Report will contain the following 
topics: 

Executive summary 

Purpose, scope and objectives 

Method of study 

Business perspective 

I/S perspective 

Findings and conclusions 

Recommendations 

Action plan for follow-on projects 

Appendices as required 

Because of the nature of a BSP study, documentation 
created during the study may prove valuable to func- 
tions within the business. While the data and analyses 
are current, the team should endeavor to publish these 
documents as ancillary output to the formal report. 

Creatine Executive Interview List and 
Schedule 

A preliminary list of executives to be interviewed 
should be prepared as early as possible. The executives 
selected will normally be within the top three levels of 
the company and be responsible for the major func- 
tions included within the study scope statement. 
Executives with cross-company responsibilities should 
also be considered. Since the need is for a perspective 
rather than specific detailed information, the ideal 
candidate is the senior executive with discrete function- 
al responsibility, e.g., director of finance, manager of 



production planning, director of marketing operations. 

The tentative executive list and schedule should be 
prepared by the team leader. Some other names may 
be added to the list during the study as the team gains 
knowledge of the company's processes. When creating 
the schedule, the team leader should consider all 
factors that may inhibit the full participation of the 
executives - vacation, important business meetings, 
public holidays, etc. 

The list of proposed executive participants should be 
reviewed and approved by the executive sponsor. 
Additions or deletions should be made and the support 
of the executive sponsor reemphasized. 

To enable the executives to prepare for the inter- 
view, an invitation letter should be sent at least one 
week before the interview. The letter should also 
confirm the time and place for the interview. Refer- 
ence to the study announcement letter previously 
signed by the chief executive officer should emphasize 
the importance of executive participation in the study 
(see Appendix B). Either within the body of the 
invitation letter or as an attachment, a list of topics for 
discussion during the interview should be included. 
Both the executive and the team members should use 
this topical outline to make the discussions more 
fruitful. Possible topics include: 

• Responsibilities 

• Objectives and plans to achieve required results 

• Business problems and value of solving them 

• Opportunities for improvement 

• Major measurements and controls 

• Identification of the key business areas 

• Anticipated changes (products, organization, etc.) 

• Evaluation of current i/s support 

• Requirements for future I/S support 

• Value of the required I/S support 

Briefing Interviewees 

The selected executives should attend a briefing session 
prior to the commencement of the executive perspec- 
tive segment of the BSP study. During this preparation 
phase, the executive briefing session should be pre- 
pared, presenters selected and exhibits prepared, so 
that the session may be delivered at the appropriate 
time during the study activities. 

Major topics which should be included in the 
briefing are: 

• Executive level overview of BSP 

• Study scope 

• Objectives of the study 

• Business reasons for conducting the study 

• Review of the expected output 

• Executive involvement - why, and what is expected 
of the executive 

• Schedule for executive interviews 
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Obtaining and Equipping Control 
Room 

Effectiveness of the BSP study depends on having a 
workroom assigned for its duration. This room is used 
both as the work location for the team and for execu- 
tive discussion session away from the executive's office. 
This approach has proved very effective in allowing 
executives to review charts and diagrams on display 
and to concentrate on discussions without interruption. 
The study room should be: 

• Located away from traffic and noise 

• Large enough to accommodate the study team plus 
one or two other people 

• Equipped with a large table, blackboard, flipchart 
stand, and lockable storage or filing cabinet 

• Able to accommodate the posting of charts on the 
walls 

• Securable to protect sensitive information 

• Equipped with a telephone only if the telephone can 
be disconnected during executive interviews 



Arranging for Administrative Support 

Typing and general administrative support will be 
required by the study team. This support should be 
estimated and organized before the major study 
activities are undertaken. Administrative activities will 
be concentrated toward the latter part of the study and 
will include executive discussion summaries, work 
plans, status reports, results of analyses, charts, final 
report, confirmation of interviews, and general secre- 
tarial support. 

Reviewing with Executive Sponsor 

Completion of the study preparation is indicated by a 
successful review meeting with the executive sponsor. 
Any issues that may have arisen during the preparation 
should have been resolved by this time. 

Items to be reviewed with executive sponsor are: 

• General results of the preparation 

• Study work plan 

• Definition of the study output 

• Approval process 

• Executive selection and discussion schedule 

• Letter of invitation to be sent to selected executives 
Everything is now prepared for the start of the BSP 

study. Experience has shown that if all the items 
discussed in Chapters 3 and 4 have been completed, the 
study results should be of high quality. 
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Chapter 5. Conducting the Kickoff Meeting 



Conducting the kickoff meeting is the first major 
activity in the formal execution of a bsp study. This, 
and the next five major activities (see Chapters 6-10) 
are all aimed at understanding the business require- 
ments and data processing support as it exists today as 
well as business requirements for the future. Since this 
understanding is vital to the success of the study, all 
these activities must be carried out conscientiously. 

Sponsor's Opening 

The kickoff meeting should be attended by all study 
team members. The executive sponsor opens the 
meeting, emphasizes the business reasons for initiating 
the study, and explains the significance of this high- 
priority program to the company. The sponsor may 
also reiterate the objectives and scope of the study and 
expected output, and offer personal commitment and 
support in the interest of seeing a successful completion 
to the study. 

Review of Study Work Plan 

The study team leader reviews the work plan and the 
Gantt chart or calendar developed during the study 
preparation phase. The work plan is used as a point of 
departure for discussing and finalizing: 

• Major events, major outputs, and schedules 

• Individual assignments 

• Project control 

This review can also serve as an opportunity to 
discuss administrative details, such as secretarial 
support, handling of phone messages, working hours, 
office security, expense charge numbers, etc. 

Business Review 

The team leader should be prepared to present, in 
summary form, the business related information 
gathered during the study preparation phase. This 
information may be new to most team members and 
should serve to broaden the business perspective of the 
team as a whole. 

Presentation emphasis should be given to business 
goals, objectives and strategies; business problems; 
organizations; geography; environment; and to infor- 
mation relative to understanding the major resources of 



the business - cash, people, facilities, materials, and 
products/services. 

Some of the material presented will be continually 
focused upon throughout the study. This selected 
information should be posted in the control room. The 
team leader may also elect to distribute hard-copy 
handouts to each team member for their own personal 
review and/or research. In any case, all presentation 
material, including detail backup, should remain in the 
control room for continued reference. Much of it will 
be placed in the Study Control File. 

Information Systems Review 

The director of I/S, or the team member representing 
I/S, should present, in summary form, the material 
gathered during study preparation. This will enable 
the study team to understand how i/s is currently 
supporting the business and planning to support it in 
the future. 

The major projects installed or being developed 
should be discussed with the study team. The discus- 
sion should include whether these projects have met or 
will meet their objectives. 

Another area that should be discussed is how data 
processing interfaces with its users, the responsibility it 
has in the development and justification of applica- 
tions, and who has responsibility for data within the 
company. 

A Copy of the presentation should be made available 
to the study team members, as it will help them later in 
the study - especially during the interviewing and 
when the team members are developing their conclu- 
sions and recommendations. 

The following is an outline for presentation of the 
I/S function: 

• Mission and objectives 

• History and background of data processing 

• Organizations 

• Overview of major application systems installed and 
planned 

• Relationship with users 

• Project approval process 

• Key problems and challenges 
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Chapter 6. Defining Business Processes 



For purposes of the BSP study, business processes are 
defined as groups of logically related decisions and 
activities required to manage the resources of the 
business. They are studied and identified without 
regard to the organization responsible for them. The 
reason for defining the processes is that doing so will 
provide or lead to: 

• Information systems with a large degree of inde- 
pendence from organization changes 

• A comprehensive understanding of how the business 
accomplishes its overall missions and objectives 

• A basis for separating the strategic planning and 
management control processes from operational 
control processes 

• A basis for defining required informatipn architec- 
ture, determining its scope, defining it so as to make 
it modular, and setting priorities for its development 

• A basis for defining key data requirements 

Lists of processes, along with some sample descrip- 
tions from both the public and private sectors, may be 
found in the appendices. 

Prerequisites to Defining Processes 

The following points are particularly relevant to 
success: 

• All members must be present and participate 
throughout the exercise and there should be general 
agreement on the expected outputs before the 
exercise begins. 

• Note-takers should be designated right from the 
beginning so that decisions and definitions of 
processes will not be forgotten or misunderstood 
later. 

• Information gathered before the start of the bsp 
must describe and size the products and resources, 
and clearly state or provide a flow diagram of the 
strategic planning and management control proce- 
dures and schedules. 

• The team must understand the concept of resources 
and their life cycle. 

The Product and Resource Life Cycle 

The manager's job is to manage the resources within 
his realm of responsibilities to most efficiently and 
effectively support the goals of the total business. By 
identifying the decision processes that he goes through 
and the activities that he performs in managing the 
resources, it is possible to gain a comprehensive 
understanding of all the business processes involved. 
The products/services may be defined as key resources 
and occupy a major role in defining the business 
processes. 



A four-stage life cycle of the product/service and of 
each of the supporting resources is used to logically 
identify and group the processes. The life cycle 
normally used is: 

• Stage 1 - Requirements, planning, measurement 
and control 

• Stage 2 - Acquisition or implementation 

• Stage 3 - Stewardship 

• Stage 4 - Retirement or disposition 

The following paragraphs refer to these stages as 
requirements, acquisition, stewardship, and retirement. 
A description of each of the life cycle stages follows: 

1 . Requirements - activities that determine how much 
of the product or resource is required, the plan for 
getting it, and measurement and control against the 
plan. 

2. Acquisition - activities performed to develop a 
product or service or to get the resources that are 
going to be used in its development. In manufactur- 
ing this would include procurement and fabrication; 
in personnel, the hiring or transfer of people; in 
education, the development of a curriculum and the 
enrollment of students. 

3. Stewardship - activities to form, refine, modify or 
maintain the supporting resources and to store or 
track the product/service. In the insurance industry 
this could be policy maintenance, premium notices 
and dividend statements; in the distribution industry 
it could include inventory control and warehousing. 

4. Retirement - those activities and decisions that 
terminate the responsibility of an organization for a 
product or service or signal the end use of a re- 
source. This might include the selling of space on an 
airline, the discharge or retiring of an employee, the 
scrapping or selling of a capital asset, or the removal 
of a service by a government agency. 

The life cycle serves as a vehicle for structured, 
logical, comprehensive identification of the processes 
by the team. 

Basic Steps in Defining Processes 

An overview of process identification is provided by 
Figure 12, which shows the three main sources for the 
identification of the business processes: planning and 
control; product/service; and supporting resources. 
Taking the latter two through their life cycle provides a 
definition of their respective business processes. 
Because strategic planning and some of management 
control are not solely product or resource oriented, 
they must be considered as a separate source to provide 
that all processes of the business are identified. 
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Figure 12. Definition of business processes 



After the product and each of the supporting 
resources have been taken through their respective life 
cycles and the processes identified and subsequently 
grouped, it is no longer necessary to retain the 
process/stage relationship for process defining, but it 
will be helpful later in identifying data classes. Since 
the life cycle is an artificial means for directing the 
team's thinking, very little time should be spent in 
deciding in which stage a given activity appears. The 
recording of the activity is more important than its 
position. 

The measurement and control processes identified 
under the requirements stage will contain both man- 
agement control and operational control activities. If 
the processes associated with strategic planning and 
management control are identified first, it will sharpen 
the distinction between management control and 
operational control and reduce some of the redundancy 
in the management control processes. The following 
descriptions of steps correspond to the flow presented 
in Figure 12. 

Planning and Control Processes 

Define the Processes of Strategic Planning and 
Management Control 

With the preparatory work that was done in collecting 
the information on planning and possible samples of 
the organization's plans, it should not be difficult to 
identify the processes involved. They will normally be 
grouped into strategic planning and management 
control. Strategic planning may be referred to as the 
long-range plan, the seven-year plan, or the develop- 
ment plan. Management control may be referred to as 
the operating plan, the management plan, the resource 
plan, and sometimes the contract plan. In some 
companies the budget may serve as a major tool for 
management planning and control. Examples of 
planning and control processes are shown in the 
following table. Further examples are contained in 
Appendix D. 



Strategic Planning 


Management Control 


Economic forecasting 


Market/product forecasting 


Organization planning 


Working capital planning 


Policy development 


Staff level planning 


Divestiture/acquisition 


Operational planning 


Analysis 


* 


Assumptions management 


Budgeting 


Goals development 


Measurement and review 


Product line modeling 
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For a detailed discussion of the theory of strategic 
planning and management control the reader may wish 
to refer to Robert N. Anthony's book entitled 
"Planning and Control Systems: A Framework for 
Analysis." 

Product/ Service Processes 

Identify the Product/Service of the Organization 

For purposes of this exercise it is assumed that there is 
one major product group or that the products are 
managed through similar business processes. In the 
case of the public sector and some service organizations 
it will help to go back to the goals to best specify the 
product or service. For example, one might think that 
the product of a health insurance organization would 
be its policies, but an examination of its goals might 
show the products to be (1) service to the subscriber 
and (2) payment to the provider. In like manner, an 
examination of the goals might keep one from assum- 
ing that the curriculum is the major product of a 
university. 

If there are two or more groups or families of 
products and services, they are discussed under 
"Expansions and Variations" at the end of this chapter. 

Identify the Processes in Each Stage of the Life Cycle 
of the Product/Service 

The general approach in identifying the processes is to 
start with the requirements stage and work through the 
succeeding stages. Care should be exercised in getting 
consistency in the level of the processes identified in 
each of the stages. Although there is no prescribed 
number of processes appearing in each of the stages, 
most studies result in only 20-60 processes for the 
whole business. The team should tend to identify more 
processes than necessary, with the idea of grouping 
them later as necessary. 

With the total team working together it is sometimes 
helpful to label each of four charts with the four stages 
and to complete them simultaneously as each process is 
brought into discussion. This eliminates the develop- 
ment of notes for the inclusion of certain items in other 
stages as they are worked upon. There is no secret 
formula for this identifying of business processes, so 
one should not be surprised if the first attempt results 
in many more processes than are needed and also a 
great inconsistency in the levels. Do not let this deter 
you; it will be corrected during the grouping of 
processes. 

It is very important that every team member partici- 
pate at all times, since business processes are the basis 
for practically everything that follows in the bsp study. 
Getting started is far more important than any theoreti- 
cal discussions on the definition of a process group or a 



process, logic, theory, or other diversions. 

The following example might result from perform- 
ing this analysis with a manufacturer of electrical and 
electronic components. 
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Marketing 
planning 


Engineering design 
and development 


Inventory 
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Selling 
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research 


Product 
specifications 


Receiving 


Order 
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Forecasting 
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records 
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Shipping 
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Production 
scheduling 


Packing and 
storing 


Fleet man- 
agement 


Material 
requirements 


Production 
operations 






Capacity 
planning 


Purchasing 







Make a General Flowchart of the Product/Service 
Processes 

A flowchart of the product/service processes (see 
Figure 13) serves several purposes: 

1. It helps in providing that all the processes have been 
identified. 

2. It helps in determining if the team really under- 
stands the business processes associated with the 
product/service. 

3. It serves as a model for the subsequent definition of 
the information architecture. 

4. It helps in identifying the processes involved in 
managing the supporting resources. 

There should be a box on the flowchart for each of 
the processes. If other boxes seem to be required, the 
definition of the processes should be reexamined. The 
flowchart will result from the identification of the 
above processes and is not intended to show the 
strategic planning and management control processes. 

Write a Description of Each Process 

A member of the team should have been making notes 
on the decisions and activities associated with each of 
the processes as they were defined by the group. 
Although this is a laborious task, it is absolutely 
mandatory if the process descriptions are going to 
reflect the knowledge of the team and the amount of 
time that has been spent in defining them. The note- 
taking job can be rotated through the team and not be 
a burden on any one individual. The descriptions may 
be either in list form or verbal. 

Completing these descriptions before moving into 
the next step will help bring out the similarities and 
differences between these processes and those subse- 
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quently identified. One of the advantages of rotating 
the note-taking among the different members is that 
the task of further defining the processes can now be 
assigned to most of the team members so that it may be 
accomplished before a description of the supporting 
resources is started. The final revision of these descrip- 
tions will probably be included in the appendix to the 
final report upon completion of the BSP study. 

The following are examples of process descriptions 
(further descriptions may be found in Appendix E): 
Production planning - the activity of planning for and 
coordinating materials, men and machines in order to 
produce the finished products needed to meet forecast- 
ed requirements 

• Capacities and capabilities planning - the process of 
balancing production need with ability 

• Scheduling - the scheduling of labor and material 
needs to meet production and shipping require- 
ments. Also, the scheduling and balancing of the 
product mix 

• Material requirements - the calculation of raw 
material needs to meet a schedule, recognizing 
optimum inventory levels, economic order quanti- 
ties, substitutions, etc. 

• Costing - establishing of standard raw material costs 
and product costs on the basis of these and other 
manufacturing and administrative cost factors 

Purchasing - the activities of acquiring materials, 
machinery and supplies of specified quality on a timely 
basis at the best price 

• Supplier evaluation and selection - the searching for, 
evaluation of, and selection of suppliers who meet 
requirements for materials, packaging, machinery, 
equipment and delivery at competitive prices 
(includes internal search) 

• Order placement and follow-up - the actual placing 
of purchase orders with approved suppliers for 
quantities of raw materials as specified (may include 
raw material routing) by production planning, 
equipment acquisitions approved by management, 
etc. (includes release of customer-purchased 
materials) 

• Receipts and inspection - the receiving or returning 
of purchased materials, machinery, and supplies, 
verifying quantity and quality, and documenting the 
activities 

Supporting Resource Processes 



While the use of only these four resources should be 
adequate, the inclusion of some ancillary resources 
might make it easier for the team to get a comprehen- 
sive list of processes. Selection can be made from the 
following list: 

• Marketplace (general public, potential customers, 
and customers) 

• Vendors 

• Documented knowledge (designs, specifications, text 
material, procedures, patents) 

• Company image (in the stock market, to the general 
public, customers, vendors, employees) 

A thorough examination of the activities and 
decisions associated with these resources should result 
in the identification of the rest of the operational 
control processes in which the business engages and 
which were not brought out in the product/services 
processes. 

The team should review the facts on resources that 
were gathered and prepared during the preparation for 
the BSP study. Before starting to identify the processes, 
it is well to place a chart on the wall with a short 
description or list of the components of the resource 
being considered. 

Identify the Processes in Each Stage of the Life Cycle 
of Each of the Supporting Resources 

The resources are taken one at a time through the four 
stages in the same manner as the product/service. The 
following chart is an example of the processes that 
might be associated with the resources. 
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Machine 


Equipment 




equipment 
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Describe the Supporting Resources 

A resource is best described as that which a business 
consumes or uses in meeting its goals. There are four 
basic resources that we deal with: 

• Materials • Facilities 

• Money • Personnel 
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Consolidation and Analysis 

Group the Processes 

The processes have been identified from the three 
sources: strategic planning and management control; 
major product/service; and supporting resources. The 
grouping should take place along the following lines: 

• Reduce inconsistencies in level. In the above 
examples of the processes, the process of manufac- 
turing and the process of accounts payable appear at 
the same level. This should be corrected. 

• Combine the processes where commonalities occur. 
As an example, purchasing may have been identi- 
fied as a process in the acquisition stage, not only for 
the product but also for materials and for facilities. 
Assuming the processes are similar, these should be 
combined into one process. As the processes were 
grouped during the requirements stage, there may 
have appeared processes entitled manpower loading, 
develop workflow plan, and schedule supply materi- 
als. These three might be grouped with the manage- 
ment control process of operational planning. 

A workable maximum is 60 processes. There will 
normally be 4-12 process groups. Some will be associ- 
ated with the resources from which they were derived. 



Marketing 


Facilities Management 


Planning 
Research 
Forecasting 


Workflow layout 
Maintenance 
Equipment performance 


Sales Operations 


Administration 


Territory management 
Selling 

Administration 
Order servicing 


General accounting 
Cost planning 
Budget accounting 


Engineering 


Finance 


Design and development 

Product specification maintenance 

Information control 


Financial planning 
Capital acquisition 
Funds management 


Production 


Human Resources 


Scheduling 
Capacity planning 
Material requirements 
Operations 


Personnel planning 

Recruiting/development 

Compensation 


Materials Management 


Management 


Purchasing 
Receiving 
Inventory control 
Shipping 


Business planning 
Organization analysis 
Review and control 
Risk management 



Figure 14. Sample list of processes by process group 

The product/service may result in two or more groups, 
and planning will account for one or two groups. 
Figure 14 is an example of grouping. Other examples 
are shown in Appendix C. 



Chart the Process Groups and Complete Descriptions 

Each process group and its processes should be listed 
on a chart and displayed for the whole team to view. 
The team should agree on the placement of each 
process under the process group, as well as the name of 
each, and should have a good understanding of all of 
them. The list should be divided among the team 
members and the writing of the descriptions should be 
completed in line with the regrouping. It is a good idea 
to have the descriptions typed so that each team may 
have them for quick reference during subsequent 
activities such as executive interviewing. It is also 
advisable to save the charts for subsequent activities. 

Relate the Business Processes to the Organization 

Once the business processes are agreed upon and 
described, they can be related to the organizational 
structure of the business to help the study team identify 
any additional people that should be interviewed and 
to further clarify their understanding of the business 
processes. Some teams may wish to complete this 
matrix before completing the process descriptions. 
Relating the organization to the processes also helps 
the team determine the information needed from the 
interviews, such as verification of executive involve- 
ment in the processes. 

To relate the business processes to the organization- 
al structure of the business, the team develops an 
organization/process matrix. Essentially, this is a 
graphic representation of one aspect of the manage- 
ment system of the organization because it illustrates 
who makes the decision in each of the processes. 

The organization/process matrix is one of several 
matrices developed as part of the bsp methodology. 
Matrices are used because they provide a convenient 
method to analyze relationships. They also provide a 
concise way to convey findings to management. 

To prepare the organization/process matrix, the 
study team uses the business processes already identi- 
fied. Using their knowledge and perspective of the 
business and the organization charts from the study 
preparation phase, the team members identify the 
organizational entities involved in the processes. 

Since the BSP study is intended to provide a broad 
overview of the business, not every organizational 
entity is identified. Furthermore, common similar 
organizations can sometimes be represented as one 
organizational unit. For example, 100 sales offices may 
be listed as a single unit. Where feasible, plants and 
laboratories should also be grouped into units. One- 
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unit representation is also generally appropriate when 
organizations of different scopes are doing the same 
job. For example, a financial planning organization 
may have three departments, each focusing on separate 
divisions. The mission of all three is still financial 
planning, and they can be represented by one organiza- 
tional unit. Figure 1 5 illustrates the organization/ 
process matrix. 

Once the processes and organizational entities are 
arranged on the matrix, the study team completes the 
matrix by indicating the degree to which each organi- 
zational entity is involved in the processes. The 
following symbols are used in Figure 15 to indicate the 
degree of involvement: 

K| Major responsibility and decision maker 

E3 Major involvement in the process 

Some involvement in the process 

When making this notation on the matrix, leave 
room for the posting of systems numbers, as explained 
in Chapter 8. 

Such indicators do not describe the actual responsi- 
bilities of each of the organizational units but serve 
only as a guide to assigned responsibility for and 
involvement in a process. Some businesses have found 
this matrix to be valuable after the study as an index to 
a management system manual, in which they develop 
responsibility and activity statements for each of the 
organization/process intersects. 

The organization/process matrix helps the study 
team validate the list of individuals to be interviewed 
and determine the questions to be asked of the individ- 
uals responsible for the processes. To authenticate the 
matrix, each person interviewed by the team should be 
asked to confirm or correct the portion of the matrix 
showing his responsibility or involvement. 

The organization/process matrix sometimes will 
show overlapping responsibility and decision-making 
authority for a process or a lack of decision-making 
responsibility for a process where it normally would be 
appropriate. Such potential problem areas are clarified 
later during the executive interviews. 

Identify Processes Key to Business Success 

This step will later aid in selecting the area of the 
business to be studied in more detail (architecture 
priority), sizing the importance of the problems 
identified, and identifying items to be stressed in the 
executive interviews. The strategic planning and 
management control processes will be some of the 
outstanding processes. One method of doing this 
identification is to rank the objectives in order of their 
importance and then determine which of the processes 
are most critical in reaching each objective. The 
process/organization matrix will also contribute to this 
selection. 



Outputs and Their Uses 

The output to be expected from defining the business 
processes consists of: 

1. A list of process groups and their processes 

2. A typed description of each of the processes 

3. A list of the processes key to the success of the 
business or designated as such on the charts of 
process groups and processes 

4. Product/services flowchart 

5. Team understanding of how the whole business 
operates and is managed and controlled 

As mentioned earlier, business processes serve as the 
base for most of the activities that follow. The ultimate 
use (of the business processes is to identify opportunities 
and requirements for the use of information systems to 
support the business. That is also one of the basic goals 
of the bsp study. 

The team members should at all times keep in mind 
that they probably will not all be working on the 
follow-on projects after the BSP study. The study 
should be regarded as an independent operation and 
the processes defined in such a way that any experi- 
enced person can read the output and understand the 
work that was done in the study. The follow-on 
projects will start with the output from the study and 
further define the processes, the problems associated 
with each of them, and the information requirements. 

Expansions and Variations in Approach 

Although following the above procedure should result 
in well-defined processes and supporting material, 
other considerations and variations are worth mention- 
ing. The more salient of these are covered in the 
remainder of this chapter. 

Diversity in Business, Product, or Service 

If the various divisions or parts of the company or the 
product/services are too diversified to have common 
processes, a grouping will be necessary before process 
identification is begun. When all the processes are 
identified, it is still highly advantageous to look for 
processes that might have common information 
requirements. 

Outside Assistance 

Even though the team members were selected with the 
aim of having their combined knowledge cover the 
entire business unit, there may be voids in that cover- 
age. If so, the team should get outside help where 
necessary for a thorough understanding of the process- 
es. Care should be taken, however, to limit the time of 
any outsider invited in and to keep that person at the 
level at which the team has been working on other 
processes. 
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Figure 15. Organization/process matrix 



Alternate Methods in Identifying Business 
Processes 

Predefined checklists of processes may be used for the 
business being studied. These may be found in the 
appendix, other BSP studies, trade publications, or IBM 
industry publications such as the Consumer Based 
Information System (CBIS) or the Communications 
Oriented Production Information Control System 
(COPICS). If this method is used, care should be exer- 
cised so that the processes are well understood by all 
the team members and do indeed represent the activi- 
ties and decisions of the business being studied. 

Generic Process Model 

An alternate approach in identifying business processes 
is to use a simple model of the business such as shown 
in Figure 16. 

The model may be expanded to fit the business. For 
instance, "demand" may become "merchandising" and 
"selling," while "supply" might break into "product 
development" and "manufacturing." The following 
further explains the model: 

1 . Supply includes processes associated with producing 
the product and obtaining the resources necessary to 
provide the products or services of the business. 
These processes normally relate to external interfac- 
es such as suppliers or vendors. 

2. Demand includes processes associated with making 
the product or service available and relates directly 
to external interfaces such as customers or clients. 



3. Requirements includes processes associated with 
determining and defining the products or services of 
the business. These processes normally involve the 
marketplace and other environmental factors. 

4. Administration includes processes associated with the 
overall accountability of the business. These nor- 
mally involve reporting activities within the organi- 
zation, such as those directly associated with admin- 
istration as well as those associated with finance, 
human resources, and facilities management. 

5. Management includes processes that tie together the 
other four aspects of the business. This aspect 
encompasses the planning, control, and measure- 
ment activities of the business. 
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Figure 16. Business process matrix 
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Chapter 7. Defining Data Classes 



A data class is a category of logically related informa- 
tion. Examples of a data class would be customer, 
vendor, product, order, inventory, etc. Since the 
purpose of information systems planning is to aid in 
managing the data resource, the data must be identi- 
fied. Defining the data classes is one approach to 
identifying the data to be managed. It also provides 
valuable assistance in reducing the possibility that data 
bases developed for early systems projects will require 
major rework to support later systems projects. Once 
the processes that support the business have been 
defined, the next step is to identify the data created, 
controlled, and used by those processes. As an aid to 
analysis, the data supporting the processes is grouped 
into data classes. 

Two approaches to identifying data class candidates 
are presented here, one based on relating data to 
business entities, the other on relating it to business 
processes. It is suggested that the two approaches both 
be used and that their results be cross-referenced to 
arrive at a final list of 30 to 60 data classes. Data 
sharing is then illustrated by relating the data classes to 
the processes that create and use them. 

Business Entity Approach 

The first approach to identifying data classes is to 
examine categories or types of data maintained by a 
business. If the life cycle of resources, previously 
discussed, is represented as in Figure 17, the types of 
data related to each stage of the life cycle can be 
defined. 

Planning data, which represents objectives or 
expectations, supports requirements activities. 
Inventory data, which maintains the resource status, 
supports stewardship activities. Transaction data effects 
changes to the inventory data caused by acquisition or 
disposition activities. At periodic intervals, summary 
data is extracted from the inventory data to provide 
feedback on how well requirements have been met. If 
each business entity is examined for each of these types 
of data, a set of data classes can be identified. 

Entities are simply things an organization or enter- 
prise is concerned about and therefore keeps informa- 
tion about, such as customers, products, materials, 




Transaction 



Inventory data 
Figure 17. Information life-cycle 

personnel, etc. Entities usually include, but are not 
limited to, the resources around which the business 
processes were defined. 

Since a data class may contain data relevant to a 
part of a business entity, an entire business entity, or a 
group of related business entities, the first step in this 
approach is to identify and list the business entities. A 
minimum starting list can be made by referring to the 
resources around which processes were defined. This 
list can then be expanded with any other significant 
entities of the business that have data related to them. 
Seven to fifteen entities are usually identified. 

Next, to identify the data classes related to those 
entities, a matrix is used, with the entities listed hori- 
zontally and the major types of data classes listed 
vertically. Six types of data class will cover most 
enterprises' requirements. In Figure 18 the six types 
are Plans/Models, Statistical/Summary, Inventory, 
and Transaction. Each entity is examined and the 
appropriate data names filled in for each data class 
type under the entity. Inventory data types are usually 
easiest to identify first, as these are the "master file" 
kinds of information. Transactions that affect the 
inventory data can next be identified, followed by the 
summary and planning types of data. 
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Figure 18. Data class/business entity matrix 
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Business Process Approach 

The second approach to identifying data classes uses 
the previously defined business processes - specifically, 
what data is created and/or used by each process. This 
approach involves constructing a series of input- 
process-output diagrams, one for each of the 20 to 60 
processes identified in the business process definition 
(see Figure 19). 

Cross-Referencing and Regrouping 

By cross-analyzing Figures 18 and 19 and regrouping 
on the basis of commonalities or inconsistencies in 
level, it is possible to compile a manageable list of 30 to 
60 data classes. 
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Figure 19. Input-process-output examples 
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Data Class to Process Analysis 

The data classes should then be placed on a matrix 
opposite the business processes, and the letters C and U 
should be entered to indicate which processes Create 
the data and which Use it. Figure 20 shows this plot, 
with the processes arranged in the life cycle sequence 
of the key resource. As this matrix shows how data is 
shared by the processes, it will be used later to develop 
the information architecture. 
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Figure 20. Data class by process, showing data creation and usage 
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Chapter 8. Analyzing Business/Systems Relationships 



Up to now, the team has been developing a new 
perspective of the business - learning to look at the 
business in terms of business processes and the data 
classes necessary to perform them. Now the team must 
develop a firm understanding of how data processing 
currently supports the business, in order to develop 
recommendations for future action. This section 
describes the use of data gathered and presented as 
part of the l/s review as well as the organization, 
process, and data class information to develop perspec- 
tives on: 

• l/s support of processes. The organization/process 
matrix developed in Chapter 6 is annotated to 
indicate which current systems support the business 
processes. 

• Usage of current data. A system/data file matrix is 
developed to identify the data files currently in use 
or planned for use by existing systems. 

(A system here is an application or grouping of 
several applications.) 

Each of these matrices is described in more detail in 
the following pages. Although the matrices provide an 
overview of the current and planned data processing 
support of the business, they cannot indicate the extent 
of support needed or the value of this support to each 
of the processes. Such information is obtained later 



during the executive interviews. Used in combination, 
these matrices are very helpful in providing the team 
with a broad overview of current systems and data 
usage. 

Understanding I/S Support of 
Processes 

In order to obtain a business- wide picture of existing 
and planned data processing support, the study team 
may opt to annotate the organization/process matrix 
with current systems support (Figure 21). The nota- 
tions on this matrix identify which organizations 
involved in the processes are receiving application 
support. This enables the study team to identify: 

• Processes receiving no current systems support 

• Processes receiving systems support in some organi- 
zational units, but not all 

• Possible redundant systems 

To create the notations, the team assigns a number 
to each of the current systems, then posts this number 
to the appropriate intersections on the organization/ 
process matrix. This may be facilitated by first creat- 
ing a system/organization matrix (Figure 22) or a 
system/process matrix (Figure 23). 
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Figure 22. System/organization matrix 
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Figure 23;, System/process matrix 



Identifying Usage of Current Data 

The team needs to understand what data is currently 
automated and where, that is, which systems utilize 
which portions of the data. The next matrix developed 
by the study team, the system/data file matrix (Figure 
24), provides this understanding. The systems annotat- 
ed in Figure 2 1 form the vertical axis of this matrix, 
while the data files, grouped by similarity, form the 
horizontal. An X is placed in each appropriate box to 
show which data files support which systems. 

This matrix sheds more light on how much data is 
shared by various systems. This, in turn, helps point 
out the need for a data base approach to provide 
consistency of data. The information gathered here 
will also be useful later in developing implementation 
priorities. 



Summary 

Some teams find it convenient to use various matrices 
as communications/presentation tools. Different 
combinations of two or more (those that share common 
axes) may be so used. 

These charts and matrices provide an overview of 
the current and presently planned data processing 
support of the business. Such information should be 
obtained from the executive interviews regarding 
problems with current data processing support and 
additional needs for information. These charts, 
together with the executive interviews, help the study 
team determine those areas where emphasis should be 
applied in developing and enhancing appropriate 
information systems. 

Appendix F contains examples of matrices from 
other industries. 
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Figure 24. System/data file matrix 
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Chapter 9. Determining the Executive Perspective 



Interviewing and interview analysis consume more 
time during the study than any other activity because 
the executive interviews are the primary source of 
information for determining the business problem and 
management's need for support in overcoming their 
problem and/or supporting new opportunities. 

The interviews are not intended to gather data on 
the specific details and exact form of the information 
required by the interviewees. 

Specifically, the purpose of the interviews is to: 

• Validate the data gathered, analyzed, and docu- 
mented in matrices and charts 

• Determine the information needed by individual 
executives as well as their problems and priorities 

• Gain executive rapport and involvement 

• Determine management values and quantify 
benefits to be derived by modifying or adding 
applications. 

The tasks that have to be accomplished in order to 
conduct the interviews are: 

• Confirm the list of executives to be interviewed that 
was developed during study preparation 

• Review the interview schedule to be certain it is 
practical, and confirm it with the interviewees 

• Organize wall charts in control room 

• Review the questions that apply to all interviewees, 
and develop individualized questions for certain 
executives, as appropriate 

• Determine the role of study team members for each 
interview and the characteristics of individual 
interviewees 

• Conduct the interview itself 

• Prepare a summary of each interview to be ap- 
proved by the interviewee 

This chapter is devoted to a discussion of these 
tasks. 

Confirming the List of Executives To 
Be Interviewed 

During bsp study preparation the team identified the 
executives that should be interviewed. The team most 
likely selected managers no more than two levels below 
the president. Now, aided by the organization/process 
matrix, the team can confirm its earlier list of inter- 
viewees and identify any other executives that should 
be included. 

Two questions can be answered using this approach: 

• What organizations are involved in each of the 
processes? 

• Within those organizations, who must be inter- 
viewed to determine the problems, objectives, and 
requirements? 



Sometimes it is difficult to assign final responsibility 
for a process to one specific organizational entity. 
Several organizations may reach a decision together. 

In some cases it is necessary to interview certain 
managers for political reasons; if they don't have an 
opportunity to participate in the study, they may 
oppose any recommendations that result from it. It 
may also be advisable to interview a particular execu- 
tive simply because other executives of the same level 
will be interviewed. This decision normally is made by 
the executive sponsor. 

Reviewing the Interview Schedule 

When the list of executives to be interviewed has been 
updated and confirmed, the study team confirms the 
interview schedule. Interview preparation time should 
always be allowed. Experience indicates that an 
effective interview requires two to four hours, exclud- 
ing preparation. Therefore, only two interviews should 
be scheduled for a given day. Normally, 10 to 20 
interviews are conducted during the study, although 
this number varies greatly with the size and require- 
ments of the business. 

It is recommended that higher executives be inter- 
viewed last. For one thing, interviewers' techniques 
and procedures improve with practice, and the team 
should be working at its best before interviewing top 
managers. Second, any suspicions or doubts the team 
may have about information obtained from the first 
executives interviewed can be resolved by formulating 
specific questions for top management. 

Preparing Questions for Interviews 

Before the interviews are conducted, the study team 
prepares a list of general questions that apply to all 
interviewees. The team also may prepare specific 
questions for certain executives, as needed. The 
following general questions, while furnished only as a 
guide, usually apply to all interviewees: 

1 . Briefly, what is your area of responsibility? 

2. What are its basic objectives? 

3. What are the three greatest problems you have 
met in achieving these objectives within the last 
year? 

4. What has prevented your solving them? 

5. What is needed to solve them? 

6. What value (in man-hours saved, dollars saved, or 
programs enhanced) would better information 
have in these areas? 

7. In what other areas of your responsibility could 
the greatest improvements be realized, given the 
needed information support? 
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8. What would be the value of these improvements in 
man-hours saved, dollars saved, or programs 
enhanced? 

9. How would you rate your information support 
with respect to adequacy ; validity, timeliness, 
consistency, cost, and volume? 

10. What is the most useful information you receive? 

1 1. How are you measured? 

12. How do you measure your subordinates? 

13. What other kinds of measurement are you expect- 
ed to make? 

14. What kinds of decisions are you expected to 
make? 

15. What major changes are anticipated in your area 
in the next year? Three years? 

16. What do you expect to result from this study? 
What does it mean to you and to the business? 

17. Do you have any additional thoughts or com- 
ments? 

The interviewer must understand the purpose of the 
general questions in order to be sure that the needed 
information is elicited. If an interviewee's response 
does not provide the information desired, it may mean 
that the question should be worded differently. Let's 
examine the purposes of the general questions and 
kinds of responses needed: 

• Questions 1-2. The interviewer asks the executives 
what their responsibilities are because conclusions 
drawn from the organization chart may not be 
correct. Also, the objectives that executives set for 
themselves in performing their functions may have a 
large bearing on their information needs. 

• Questions 3-6. When asking about problems, the 
team should be sure that the executives do not 
indicate only their last problems. Sometimes people 
overlook more serious problems that occurred 
months before. 

• Questions 7-9. The information satisfaction and 
needs questions should focus on the additional costs 
that may be incurred from inaccurate and untimely 
information. The value of any additional informa- 
tion desired should also be determined. 

• Question 10. The team must determine where the 
current information support is adequate so that 
these benefits are retained. 

• Questions 11-13. The questions concerning meas- 
urement are intended to disclose how the effective- 
ness of resource allocation and use is measured. A 
major factor in business success is efficient use of 
resources. 

• Question 14. The question on what decisions are 
made is intended to disclose whether executives 
receive adequate information on which to base 
them. 



• Question 15. The questions on anticipated changes 
are important because major information systems 
development cycles can take from two to five years 
to complete. Recommendations for information 
systems development could be impacted by plans to 
centralize, decentralize, change the organization, 
introduce new products, etc. 

• Question 16. The questions regarding expectations 
for the BSP study may help the study team ascertain 
how likely management is to accept and implement 
the study recommendations. 

• Question 17. Additional thoughts and comments 
make an appropriate way to terminate the interview. 

Determining Team M emberlnterview 
Roles and Interviewee Characteristics 

One of the tasks that must be performed when prepar- 
ing for interviewing is to assign roles for team members 
to play during the interviews. There are several factors 
to consider when making these assignments. 

The interview team is drawn solely from study team 
members and may include IBM representatives. Re- 
gardless of the number of people on the study team, 
there are usually no more than four active team 
members present at any particular interview. 

A given team member need not play the same role 
in each interview. Furthermore, some members are — 
usually assigned to more than one role in an interview. 
The following roles should be filled: 

• An individual to present the study objectives and 
approach to the interviewee. This person may have 
another role in the interview as well. 

• An interviewer. 

• A backup interviewer to listen carefully to the 
proceedings to make sure that all questions are 
asked and that all answers are understood. The 
backup interviewer asks any additional questions 
necessary. 

• Someone to take notes during the interview and 
have them organized, typed, and presented to the 
interviewee afterwards for approval. 

• A supplementary note-taker if the situation requires. 
Sometimes the interviewee is a member of a depart- 
ment in which a team member serves. Because of the 
possible sensitivity of some of the information, it may 
not be advisable for that team member to be an 
interviewer during that session. Perhaps the individual 
should not even be present. Similarly, if there are any 
personality clashes between an interviewee and a 
particular team member, that team member should 
probably not be presented at the session. 

In determining who will serve in what roles, consid- 
eration should be given to individual abilities. Some 
people are better speakers than others; some are fast 
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and accurate note-takers. The interviewer for any 
session should be chosen for knowledge of the area of 
the business to be investigated and for ability to 
achieve rapport with the interviewee. 

Before each interview session, the study team should 
meet to discuss various matters that are specific to that 
interview. The responsibility of individual team 
members during the interview has already been 
covered. The study team should also review: 

• Background of the interviewee 

• Responsibilities of the interviewee 

• Process in which the interviewee is involved 

• Data processing support provided to the 
interviewee's area of responsibility 

• Specific questions to ask the interviewee, which may 
be based on prior interviews with other executives 

Conducting Interviews 

The best location for interviews is the study control 
room, where interruptions are least likely and where 
the matrices and charts can be displayed on the walls 
for reference. If the control room is close to executive 
offices, it should be convenient for the interviewees. 
The following sequence of activities will normally 
transpire after the interviewee arrives and has been 
introduced to the interview team: 

• The interviewee should be walked through the wall 
charts by the interviewer and he should be asked to 
validate the data on the charts. There should be 
agreement between the interviewee and the study 
team on the business process definitions and their 
relation to the organizational entities, particularly 
within the interviewee's area of the business. Make 
changes to the wall charts if necessary. (See Appen- 
dix G.) 

• The interviewee is seated so that he can see the wall 
charts during the interview. This should make the 
interviewee more comfortable and thus enhance 
support. 

• All the general questions and any specific questions 
previously formulated are asked. Many questions 
are likely to arise in the course of the interview and 
these are also asked. 

As indicated before, the interviewer often needs to 
ask more questions than were prepared. It is impossi- 
ble to predict all the possible responses that an execu- 
tive might offer. From statements made during the 
interview, new questions are bound to arise. Further- 
more, questions often must be formulated or restated 
during the interview to elicit the exact information 
needed. This is particularly true when trying to secure 
value statements that can be quantified, especially 
when discussing intangibles. 

Following are some techniques that can be used to 
prompt an interviewee to express values quantifiably: 



• Have the interviewee express a potential benefit as a 
percentage. 

• Have the interviewee express a potential benefit in 
terms of a range - for example, a saving of $200,000 
to $400,000. 

• If the interviewee gives an exceptionally high value 
that might not be acceptable to other managers, 
suggest using 50 percent of that figure. 

• In a particular operational area, cite' a well-known 
industry average. 

• Determine the company's present position in the 
industry and ask what it would be worth to be in a 
stronger position. 

• Employ in-depth logical questioning. If the value of 
a particular benefit cannot be quantified by the 
interviewee, try to break down the various costs of 
not having the benefit. 

• Determine the objectives against which the execu- 
tive is measured and what it would be worth to 
achieve those objectives. 

• Determine what the company is currently spending, 
what the forecasts are, and how these spending 
levels would be affected if a certain capability were 
available. 

The interviewer must be sensitive to the responses of 
the executive in order to probe more deeply into any 
subject area when appropriate. Team members should 
be attentive to the executive's tone of voice and facial 
expressions, which are often a key to underlying 
feelings. 

Preparing Interview Summaries 

The study team should keep current with the documen- 
tation of the interviews. Immediately after the inter- 
view has been concluded, the two study team members 
who were taking notes during the interview should pull 
the notes together and have them summarized and 
typed. 

Summaries should be formatted so that problem 
statements and key points appear in separate para- 
graphs. Each problem statement and key point can 
then be easily extracted for later analytical work. The 
summaries are reviewed by the team leader, then 
presented to the interviewee for approval. The inter- 
viewees should approve and return them to the study 
team within two days after the interview so that all 
team members can keep informed. Copies should be 
given to all the team members and one copy filed as the 
official study team document. 

In addition, any changes resulting from the inter- 
view should be posted to the wall charts to keep them 
as accurate as possible. 

As the interview summaries are returned, the study 
team members can begin to assess the business prob- 
lems and/or opportunities (see Chapter 10). 
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Chapter 10. Assessing Business Problems and 
Benefits 



The reduction and use of data obtained during the BSP 
interview process is extremely important. This chapter 
presents a structured and proven procedure to organize 
interview data and provide a useful format for later use 
in determining information architecture and priorities. 
Figure 25 presents a logical flowchart of the data 
reduction procedure and is keyed to the text by step 
number. 



Interview 
Notes 



Problems, 
Solutions 
& Values 



l/S 

Problems, 
Solutions & values 
For existing system 



Step 1 




l/S 

Needs & values 

Where no system 

Exists 




Non - l/S 
Problems 



Step 2 

To 
— executive 
sponsor 



Step 3 



To information architecture 
and priorities 

Figure 25. Data reduction steps 

Step 1: Summarize Interview Data 

The team selects out of each set of interview notes 
(1) the problems, (2) solutions (if given), (3) value 
statements - tangible or intangible - if given, (4) the 
processes impacted, and (5) the processes causing the 
problems. 

Problems as stated by the businessman may be 
"perceived problems" (that is, perceived from the 
impact they make on a particular process) or they may 
be actual root-cause problems. "Perceived problems" 
are necessarily the starting point for problem assess- 
ment in BSP. A perceived problem is something a 
businessman sees as a problem. It may turn out to be a 
real problem, an incomplete version of a real problem, 
or just a symptom of one. 

In order to assess problems objectively, therefore, 
perceived problems must first be traced back to root 
causes and forward to end-effects. The loss represent- 



ed by each end-effect may then be quantified as far as 
possible, and the relative contributions of root causes to 
that loss may be assessed. 

Figure 26 illustrates the worksheet to be used in this 
step. The team, as a unit, then considers the individual 
analyses and drafts a composite list of problems, 
solutions and values. The team must take care to select 
only stated problems and not implied problems. If the 
team decides that an implied problem is of a magni- 
tude and importance that it should be further clarified, 
communication with the interviewee on a formal or 
informal basis should be undertaken in order to 
establish the specifics and/or magnitude of the 
"implied problem." If the communication establishes 
additional significant data not in the original notes, it ,, 
must be added as an addendum to the validated 
original notes with reference to the follow-on commu- 
nications. A copy of the addendum must be forwarded 
to the interviewee for his validation. 

The entire composite list should now be typed with 
double spacing between entries. Each entry must be 
code-connected to the original interviewee. Assigning 
a number or letter or combination of same to each 
interviewee allows his identity code to be attached to 
each entry, while maintaining confidentiality. 

Step 2: Classify Interview Data 

Using the interview notes and worksheets, the team 
now examines each line entry and establishes whether 
it is in the category of: 

1 . i/S problems/solutions and values (existing systems) 

2. l/S needs and values (no system exists) 

3. Non-i/s problems 

Sometimes a problem will have both an organiza- 
tional solution and an i/s solution. Example: "There 
is a need for better marketing research information." 
This may require that a research group be established 
to gather information and an information system be 
developed to store and manipulate the information. At 
the end of step 2, the line entries extracted from the 
interview process should be in the three categories 
named above. 

It is critical at this point that the "non-l/s problems" 
be logically grouped, stripped of all identity, and very 
carefully handled. It is not the mission of the BSP study 
team to solve the non-l/s problems. However, the 
information obtained in the interview processes, which 
relates to these problems, is important and should be 
properly presented to the appropriate individual 
(usually the sponsor) for his consideration and appro- 
priate action. 
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Interviewee: Mr. H.R. Zimmer, Vice President of Production 
Team Member: Mel Aksarben Date: August 24, 1978 



Major Problem 


Problem Solution 


Value Statement 


Information 
System Needs 


Process/Group 
Impacted 


Process/Group 
Causing 


Lack of effective 
production planning 
impairs profit- 
ability 


Mechanized pro- 
duction planning 


Improve profit; 
improve customer 
relations; improve 
service of supply 


Production 
planning 


Production 


Production 


Increasing account- 
ability of board of 
directors; demand 
for financial and 
management 
auditing 


Better information 


Increase value from 
outside directors 


Cost system 


Finance 


Finance 


Lack of "what if" 
capability on cost 
sheets 


Mechanized online 
cost sheet capa- 
bility 


Improve profit; better 
customer relations 


Cost system 


Finance 


Administration 


Inability to look at 
enough alternatives 
in business planning 


Financial modeling 
("what if" capa- 
bility) 


Raise profit; curtail 
losses; improve growth 


Planning simula- 
tion 


Finance/management 


Management 


Lack of ability to 
identify and pro- 
mote qualified 
people 


Better information 
on personnel re- 
sources 


Retain good people; 
improve morale 


Skills inventory 
system 


Human Resources 


Human Resources 


Lack of expertise in 
marketing impairs 
growth and profits 


More marketing 
awareness and more 
people with market- 
ing expertise 


Satisfy customers 




Marketing 


Human Resources 


Loss of ability to 
effectively transfer 
people; low produc- 
tivity. Long training 


Description of work 
to be done in each 
area 


Manage people prop- 
erly; improve quality 
of work; increase pro- 
ductivity 


Order status 


Human Resources 


Sales Operations 


Poor customer re- 
lations; loss of 
profit; excessive 
inventory 


Better sales analysis 
and productive 
planning; better 
buyer reports 


Improve customer 
relations 


Order status 


Marketing 


Sales Operations 


Poor customer re- 
lations; loss of 
profit; excessive 
inventory 


Better sales analysis 
and productive plan- 
ning; better buyer 
reports 


Improve customer 
relations 


Production 
planning 


Marketing 


Production 


Poor customer 
relations; loss of 
profit; excessive in- 
ventory 


Better sales analysis 
and productive plan- 
ning; better buyer 
reports 


Improve customer 
relations 


Sales analysis 


Marketing 


Marketing 


Smaller, more 
frequent orders; lead 
times too critical; 
higher cost of 
handling orders 


Order trend 
analysis/costs 


Control cost better 


Territory analysis 


Sales Operations 


Sales Operations 



Figure 26. Interview analysis and data reduction worksheet 
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Step 3: Relate Data to Processes 

All of those interview entries which were grouped as i/s 
problems/solutions or i/s needs and values should now 
be cut from the worksheet. Example: 



K-2 
Lack of effective 
production planning 
impairs profit- 
ability 


Mechanized pro- 
duction planning 


Improve profit; 
improve customer 
relations; improve 
service of supply 


Production 
planning 


Production 


Production 



Next a flipchart page should be created for each 
business process group and its processes. These should 
be arranged around the control room at a level handy 
to "post" to. Team members then take each of the 
prepared interview entries and stick them onto the 
flipchart for the business process that causes the 
problem. If possible, the entry should be placed within 
the process most appropriate. 

Don't worry about being too precise on the first 
"posting." Additional teamwork is required to finalize 
the procedures. 

When all entries have been "posted," the team 
concentrates on one business process at a time to 
ensure that all entries have been posted to the right 
process. It is normal to have to go back to the original 



validated interview notes or even the original hand- 
written notes to firmly establish the topic area and 
background that triggered the interview comment 
(entry). The need for mobility of the item entries 
quickly becomes obvious during this fine-tuning step. 

Summary 

It is possible to group the interview data entries in 
several ways. They may be related to the causing 
processes or the impacted processes using matrices as 
illustrated in Figure 27 or in other summary formats as 
appropriate. This data will provide valuable perspec- 
tive as the team develops recommendations on infor- 
mation architecture and systems priorities. 
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Inventory Level Consistency 
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Control of Production Costs 
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Working Capital Management 
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Job Descriptions 
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// 
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9 



Figure 27. Problem/process matrix, showing the number of times 
the problems were stated 
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Chapter 11. Defining Information Architecture 



Having acquired an understanding of the business 
processes and the data required to support them, the 
team should continue its analysis by determining how 
the data will be managed to support the processes. The 
data classes that have been identified can be logically 
grouped into data bases. Information systems then 
become the vehicles used to insert data into and extract 
it from data bases, and formulate useful management 
information to support the business processes. 




In order to identify the information systems and 
subsystems areas to be developed, an information 
architecture is defined, using a diagram that shows the 
relationship of data to systems and the processes 
supported by each. The architecture diagram, then, is 
the blueprint that outlines for each system area ( 1 ) the 
data created, controlled and used, (2) the relationship 
of system to system, and (3) the systems that support a 
given process. The architecture diagram allows us to 
take into consideration the data requirements of later 
subsystems at the time of developing earlier subsystems 
in order to maximize sharing of data. 

First, the architecture is developed by evolving 
through several iterations of a process/data class 
matrix. Data flow is then added to the architecture, 
followed by subsystem identification and analysis of 
subsystems for prerequisites. 



Developing the Architecture Diagram 

Begin with the process/data class matrix where the 
process axis is in life cycle sequence based upon the 
key resource, as in Figure 28. Next, arrange the data 
axis by taking all data classes created by the first 
process and grouping them to the left, or origin of the 
matrix. Group all data classes created by the second 
process next to those created by the first process and 
continue this grouping until all data classes are cov- 
ered. Figure 29 shows the result, with all "creates" 
grouped diagonally from the matrix origin to the 
opposite corner. 

Although the next step is somewhat a matter of 
judgment, the object is to group the processes and data 
into major systems areas. This can be accomplished by 
looking at the process groups and the data created by 
them, then boxing in these groupings as in Figure 30. 
Where a process group creates no data, the box is 
arbitrary. The boxes represent logical subsystem 
groupings with responsibility for creating and main- 
taining specific related classes of data. 
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Figure 28. Data class by process, showing data creation and usage 
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Figure 29. Data classes arranged by creating process 
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Figure 30. Process/data class groupings 
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Data Flow 

Where the U falls outside a system box, a means to 
represent data flow from one system area to another is 
desirable. This flow is represented by arrows in Figure 
3 1 . The third system down uses "Product" data 
created by the second system. The arrow shows data 



flow from the second to the third system. The second 
system uses "Customer" data created by the fourth 
system, so an arrow indicates this data flow. Figure 32 
shows all data flow from system to system represented 
by one-way arrows. This figure will be used later for 
subsystem identification. 
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Figure 31. Data flow determination 
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Figure 32. Data flow 
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With data creation and use indicated by the boxes 
and arrows, the Cs and Us may be eliminated and 
names applied to the major systems areas (Figure 33). 
While Figure 33 represents the completed information 
architecture, a final rearrangement of axes and use of 
two-way arrows allows preparation of a simplified 
graphic of the architecture. Figure 34 shows such a 
graphic with the same systems. Such illustrations have 
proved useful in management communications regard- 
ing the information architecture. 
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Figure 34. Graphic rearrangement of information architecture 



Subsystem Identification 

The first cut at identifying subsystems is again an 
arbitrary classification. Using the architecture devel- 
opment diagram such as Figure 30, define each C as a 
create subsystem. Define each U associated with a 
given process as a single usage subsystem. 

With this starting point, logical combinations 
and/or splits can be made. Usage subsystems can be 
combined where use of the data is similar. Where 
create and usage subsystems are highly interdependent, 
a combination may be logical. Where a usage subsys- 
tem has dissimilar functions included, it can be split 
into two or more subsystems. 

When the subsystems have been identified, a 
description of the functions of each (approximately one 
paragraph) should be written. 

» 

Analyzing for Prerequisites 

With an outline of subsystems at hand, the final step is 
a prerequisite analysis, i.e., which subsystems must be 
in place before others can be created. By using the 
information architecture just developed and the team's 
understanding of the business, the interdependencies 
among subsystems can be analyzed. Once more, a 
matrix can be used to tabulate the results of the 
prerequisite analysis. The vertical axis of the matrix 
should list all subsystems, while the horizontal should 
list the prerequisite subsystems (Figure 35). 



PREREQUISITE 
SUBSYSTEM 



ALL 
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Engineering design 



Order specification 
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Product data control 



Sales analysis 



X 



X 



X 



X 



X 



X 



















Order entry 










X 






Business plan assessment 






X 











Figure 35. Prerequisite subsystem analysis 

Architecture Use 

The information architecture identifies the systems and 
subsystems with respect to the data they create, control 
and use, and with respect to the business processes they 
support. The interdependencies have been analyzed as 
a basis for the prioritizing and planning that now take 
place. The information architecture provides an 
excellent foundation for analysis of distributed infor- 
mation systems requirements and data base planning, 
subjects covered further in Chapter 16. As each step is 
taken in development of the information systems, the 
architecture provides a blueprint showing where each 
piece of the system fits and what its relationship to the 
other pieces is. 
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Chapter 12. Determining Architecture Priorities 



The team should select and recommend to manage- 
ment a portion of the information architecture to be 
implemented first. The purpose of identifying and 
recommending such a follow-on project is to begin 
implementation as early as practical. This will estab- 
lish a "pay as you go" foundation for implementation 
of information systems. 

The activity of selecting first subsystem(s) should 
rely primarily on a value analysis activity following the 
interviews. Its purpose is to produce a priority se- 
quence of subsystem(s) that were identified in the 
information architecture activity of the BSP. The tasks 
to be performed are: 

1 . Determine selection criteria and document the 
technique to be used 

2. Apply criteria to the subsystems 

3. List subsystems in priority sequence 

4. List dependencies or projects that are prerequisite to 
the first subsystems 

5. Document or describe the recommended subsystems 

Determine Selection Criteria 

Since data is now being treated as a business resource, 
I/S projects should be able to be evaluated by manage- 
ment in the same way other business projects are 
evaluated. Therefore, it is recommended that the team 
use whatever justification technique presently exists 
within the organization for evaluating new projects. 
This will ease decision making as executive manage- 
ment makes the necessary trade-offs between, say, 
developing a new product, expanding a facility, 
making an acquisition, or implementing a major 
information system. 

Some of the questions to be answered in determin- 
ing the first subsystem(s) are: 

• Will the subsystem provide a significant near-term 
saving and a substantial long-term return on 
investment? 

• Whom will it impact, and how many people will be 
involved? 

• Will it lay the groundwork for an initial data base 
structure for the architecture? 

A method of determining logical priorities is to 
group the major criteria into four categories: 

1. Potential benefits (value judgments) 

• Tangibles 

• Intangibles 

• ROI 

2. Impact , 

• Number of organizations and people affected 

• Qualitative effect 

• Effect on accomplishing overall objectives 



3. Success 

• Degree of business acceptance 

• Probability of implementation 

• Prerequisites 

• Length of implementation 

• Risk 

• Resources available 

4. Demand 

• Value of existing systems 

• Relationship with other systems 

• Political overtones 

• Need 

Apply Criteria and List Systems 

The major systems comprising the architecture can 
then be analyzed as potential first-subsystem candi- 
dates and ranked on a scale of 1 to 10 for each of the 
four categories above. Some type of pictorial represen- 
tation can then be drawn to emphasize the most needed 
subsystems. Figure 36 is an example of this analysis. 

List Prerequisites 

During the architecture development activity, the team 
prepared a matrix to identify system prerequisites 
(Figure 35). Once a first system has been identified, 
the team should review that matrix. Any steps or 
projects necessary for successful implementation of the 
selected first system should be sequenced and listed. 
This will be necessary for developing a meaningful 
action plan. Prerequisite projects should then be 
clearly described and their relationship to the selected 
first system defined. 

Document Recommended System 

Finally, the recommended first system (or first subsys- 
tems) should be further documented. The system 
should be described in sufficient detail that the execu- 
tive can properly evaluate it. The description should 
include an overview of system functions, major purpos- 
es and processes supported. It should identify any new 
technologies and/or special skills that need to be 
acquired or developed in order to implement or operate 
the recommended new systems. A general description 
of perceived benefits anticipated should also be 
included. The recommendation, documentation, and 
presentation should be in a format consistent with 
standard company practice. 
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Because of resource limitations, the definition of 
more than the very highest priority systems may be 
impossible initially. However, the same method can be 
used in making later selections. After the implementa- 
tion of the first system has been completed, the priori- 
ties of the remaining system should be reassessed. For 
example, after the first four systems have been imple- 
mented, the system initially listed fifth may no longer 
be at the top of the list because the requirements and ' 
problems of the business have changed. 



Expansions and Variations 

Another method that may be used for priority selection 
is to focus primarily on financial justification. Using 
this technique, the team attempts to focus on tangible 
benefits as provided in the value statements during the 
executive interviews. This technique, called risk- 
benefit analysis, is described in Appendix H. 



Potential Benefits Impact Success Demand 

Maximum Score H m// 1 1 L 1 1 1 1 1 



Subsystem 

Production Planning 

Production Scheduling 

Plant Status 

Order Entry 

Order Status 

Sales Control 

Cost 

Bills of Material 

Product Data Control 

Purchasing 

Raw Materials Inventory 

Finished Goods Inventory 

Sales Analysis 

Forecasting 

Financial Modeling 

Territory Analysis 

Engineering Design 

Skills Inventory 

Compensation Administration 

Financial Planning 



40 



Ranking Score 



lllllllh 



M£Ilv^l33 



Mlllllllk 



HSH^]32 



1//////A 



Nbsksk^ m 



Mill ll I lt\ \mmmmtM 7* 



Mill III l\ 



Mimiiin 



\uiiniu\ 



\ iimn\ 



HI 25 



limn 



mm-m n 



lll llh 



mmmm ™ 



ZZZZZZZ 



mm* 



II III 1 1\ fcssssq a 
TMMMM™ 



I////// 1 



7777T 



21 



//////I 



|:=:::=:::::3 21 



nun 



mm 21 



TELL 



11111] 21 



TEL 



mm ™ 



inn mm ™ 



T7TTT 



mils 



28 



111 28 



27 



Figure 36. Sample subsystem ranking 
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Chapter 13* Reviewing Information Systems 
Management 



The development and implementation of the informa- 
tion architecture cannot be accomplished without 
adequate planning, measurement, and control in the 
information systems functions. This chapter deals with 
those activities required to adequately review the 
Information Systems Management (ISM) function so as 
to recommend immediate changes and to specify ism 
activities that are part of the follow-on projects. 
The bsp study will not encompass all the ism 
functions. The ism analysis should be at the level of 
the i/s director's view and should include only the 
planning and control aspects of the major i/s processes. 
To put the ISM activities into perspective, this chapter 
starts with a definition of ISM and then goes on to the 
objectives of the ISM module in the BSP study. 

Purpose of ISM in the BSP Study 

The purpose of Information Systems Management is to 
manage the I/s resources for the most efficient and 
effective support of the business. The management 
system helps provide the continuous planning, control, 
measurement, and operation of the information 
systems function. An example of the total spectrum of 
ism processes is represented by Appendix I. 

ISM as Part of the BSP Study 

The objectives of the ISM module are to: 

• Study the facts relating to ISM produced in other 
modules of the bsp study 

• Understand the findings and conclusions on i/s 
support of the business in relation to ISM 

• Further specify i/s objectives 

• Ensure that the first subsystems selected will be 
supported by the current or planned ISM functions 

• Identify those ISM projects that have high priority 
and should be follow-on ISM projects 

ISM Inputs 

There are actions in other study modules prerequisite 
to performing the ISM activities in the BSP study: 

• From study preparation: 
I/S mission and objectives 
i/s plans and strategies 
i/s measurements 

I/S organization 

I/S budgets 

I/S trends (resources, expenses) 

I/S inventory and locations (equipment, software, 

systems, personnel) 



• From determining business requirements: 
Description of business objectives 

I/S support problems (from executive interviews) 
Major ISM problems/requirements from DP 
* director's I/s review) 

• From determining architectural priorities: 

New technologies and skills required to support the 
development of the first subsystem(s) 

Flow of Activities in the ISM Module 

Figure 37 gives an overview of the activities involved in 
the ISM module. The activities in italics are not part of 
this exercise but are included to help the reader see 
where ISM fits with the other activities. As noted in the 
figure, the required ISM changes are developed through 
three channels: 

1 . I/S objectives 

2. Information architecture 

3. Problem analysis 
I/S problems 
ism problems 

The changes required by each of these are then 
consolidated into a list /or developing ISM priorities, 
which serves as input to the ISM portion of the action 
plan resulting from the BSP study. 

Compiling the I/S Objectives 

The I/S objectives are required to provide the frame- 
work to provide consistency in the development and 
employment of i/s resources in support of the business. 
I/s objectives must be consistent with the objectives 
and management systems of the business so as to serve 
as a guide for the development of i/s plans and strate- 
gies in the BSP follow-on activities. 

The current I/S objectives were documented in the 
BSP study preparation phase and discussed in the I/S 
director's presentation. 

In determining the present I/S objectives to be 
modified and additional objectives that should be 
defined, the following list can be used as a guide. The 
objectives can be specified by defining the long-term 
view of each of these categories in information systems. 
1. I/S Personnel 

Organization 

Skill mix 

Development and training 
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but added to the chart for 
purposes of perspective on ISM 



Figure 37. Flow of ISM in a BSP study 



61 



2. I/S Finance 
Appropriations 
Expense budget 
User budget for i/s 

3. User 
Capability 
Responsibility 

Development 
Data management 

4. i/s Facilities 

Processing sites (data center - user locations) 

Equipment 

Software 

Communications network 

5. Applications 

6. Data 

The following is a sample of i/s objectives following 
this approach: 
Personnel 

1. Provide staff assistance for planning and control 
to all levels of I/S line management. 

2. Centralize major development and control 
functions with decentralized operations. 

3. Develop i/s. personnel who are specialists for each 
function of the business. 

User 

1. Provide maximum data processing capability and 
data access to users while maintaining central 
control. 

2. Establish user responsibility for information 
requirements and validity of l/s outputs during 
the external design phase. 

Following this procedure in compiling the i/s 
objectives should result in implied changes to ISM. 
These changes should be listed and reviewed with the 
I/S director and then held for later consolidation in the 
establishing of ISM project priorities. 

Ensuring ISM Supports Architectural Priorities 

As Figure 37 shows, the architectural priorities are a 
major input in determining the changes to ISM. The 
first data bases and information systems will probably 
require new technologies that must be provided and 
managed. They may also require new management 
practices. For example, a move to distributed data 
processing may require new practices regarding 
funding, chargeouts, control, and education. List these 
changes and save them for the consolidation. 

Problem Analysis 

Rearrange I/S Support Problems by Type 

The third channel for identifying ism changes is 
problem analysis. The problems that have been 
identified in the BSP study are separated into i/s 



support problems and non-i/s problems. Although the 
I/s support problems may have been aligned with 
business processes and with data, they should be 
rearranged at this time for better evaluation of their 
solutions through changes to ism. The rearrangement 
should result in the categorizing of the problems by the 
following ism processes for ease of defining and 
implementing changes: strategic planning, manage- 
ment control, I/S development, systems management, 
data administration, and organization and administra- 
tion. Categorizing the problems by ISM processes will 
also provide direct input to the follow-on activities. 

After rearranging the I/S support problems by type, 
check to see that those resulting from inadequate or 
nonexistent systems have been addressed by the 
proposed information architecture. This may identify 
changes to existing systems. Such information would 
be given to the I/s director for appropriate action. The 
other problems should be translated into required ISM 
changes. For example, the inaccessibility of existing 
data may require a change to the user function, giving 
the user direct access to selected data through his 
terminal. This would be in line with the objective to 
distribute more data processing capability to the users 
and require additional controls. After listing the 
required ISM changes, hold them for combining with 
the ones resulting from the next step. 

Extract ISM Problems from I/S Review 

During the kickoff, the director of information systems, 
or his representative, gave a review of the status of 
information systems in the company. Part of that 
review covered current problems in information 
systems management. There is a significant difference 
between these problems and those in the preceding 
paragraph. The i/s support problems may imply 
problems in ism or may be attributable to other causes, 
whereas specific ISM problems may be spelled out 
during the i/s review. Categorize this set of problems 
also by information systems processes. 

Because one of the major BSP objectives is the 
development of a long-range information systems plan, 
it should receive major emphasis during problem 
analysis and it must, of course, be one of the follow-on 
projects. Of equal importance with i/s planning is the 
subject of data management. Since data has been 
identified as a corporate resource, a major emphasis 
must be put on its management. This also will be one 
of the follow-on projects in ISM; both it and I/s plan- 
ning will be elaborated upon more fully in Chapter 16. 

Consolidating and Prioritizing ISM Changes 

Consolidate all of the implied ISM changes from the 
three sources. Develop criteria to be used to rank the 
ISM changes, such as impact, potential benefits, resour- 
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ces involved, and probability of successful implementa- 
tion. Apply weights for each factor and determine the 
total weight and priority associated with each of the 
ISM changes. This selection process should parallel 
that used in establishing the architectural priorities. 

Developing Recommendations and Action Plan 

Although the above activity will give priorities, do not 
establish schedules until this list is combined with 
actions required for other follow-on activities. The 
developing of recommendations and an action plan is 
covered in the next chapter. 



ISM Outputs of a BSP Study 

The following list summarizes the outputs that should 
result from the ISM portion of the bsp study: 

1. Findings and conclusions 
Major ism problem analysis 

ISM problems deduced from the i/s support prob- 
lems 

2. i/s objectives 

3. Definition of high-priority ISM projects 
First systems support requirements 
Projects addressing major ism problems 
Immediate actions recommended 

4. Action plan for follow-on projects 
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Chapter 14. Developing Recommendations and Action Plan 



Specific BSP study recommendations may center on the 
areas of: 

1. Information architecture 

a. Detailing the subsystems of the information 
network 

b. Interim improvements to current systems 

2. Information systems management, including: 

a. Data management to control the data resource of 
the organization 

b. Information systems planning process to ensure 
that the information architecture remains respon- 
sive to changing conditions 

c. Measurement and control to provide a system of 
procedures, controls and structure for future 
implementations 

3. Architecture priorities - development of the first 
system to be implemented 

For each recommendation, there may be an associ- 
ated project, and for every project an action plan 
should be developed identifying the key decisions and 
activities required to help management provide proper 
direction. The action plan should give the project 
manager a firm basis for a smooth transition from the 
study work product to the particular project. The plan 
should describe the costs, potential benefits, and 
schedules for each project in enough detail that an 
informed executive decision can be made to approve or 
reject the project. 

Each action plan should include the following: 
Scope of project. Describe subject of project, includ- 
ing size and purpose. 

Deliverables. List and define each output or result 
expected of the project. 

Schedule. Identify expected start and concluding 
dates as specifically as possible. 



Potential benefits. Describe anticipated benefits or 
reasons for doing the project. 
People and skills. Describe manning of project in 
terms of management as well as staffing. 
Tools and techniques. Describe any required prac- 
tices or methods as specifically as possible. 
Training. Describe specific orientation, education, 
and study necessary for successful execution of the 
project. 

Communications. Identify coordination, liaison, 
interface points, or functions as well as documenta- 
tion requirements. 

Logistics. Define materiel and facility support 
necessary and indicate when it is needed. 
Control. Define project control methods and respon- 
sibilities as well as review/approval requirements. 
The amount of emphasis placed on the recommend- 
ed follow-on projects varies greatly from one organiza- 
tion to another. Normally, multiple follow-on projects 
will run concurrently. The number of simultaneous 
system projects varies with the needs of the organiza- 
tion, the resources and time available to perform each 
project, and other factors. 

The completion of the activities above enables the 
BSP study team to proceed to its final activities: prepa- 
ration of the study report and presentation of the study 
results to executive management. Thorough prepara- 
tion of the action plans, potential benefits, and costs 
enables the executive sponsor to evaluate the recom- 
mendations. The study team can then ask for and 
expect a prompt approval of the recommendations and 
a prompt commitment by management to implement 
them. 
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Chapter 15. Reporting Results 



Having defined the information architecture, identified 
the architecture priorities, reviewed and assessed i/s 
management, and developed recommendations and the 
action plan, the BSP study team is ready to complete its 
mission by preparing the study report and preparing 
and delivering an executive presentation. The purpose 
of the report and presentation is to obtain further 
executive management commitment and involvement 
for implementing recommendations from the BSP 
study. 

The following activities are performed in preparing 
the study report and executive presentation: 

• Report outline is prepared 

• Report is written 

• Executive presentation medium is determined 

• Executive presentation is prepared and delivered 

Report Outline 

During the initial steps of preparing for the study and 
developing a work plan for conducting the study, the 
team prepared a preliminary report outline. Since the 
report now materializing from that outline is to be a 
consensus of the entire team, each of its sections should 
be reviewed by each of the members so that the final 
document reflects all their comments. 

The report may be structured in many ways, de- 
pending upon precedent and methods of presentation 
within the business conducting the study. However, to 
assist the team in its consideration of pertinent areas, 
an extensive list of topics is presented in Appendix J. 

The most significant findings, conclusions, and 
recommendations should be summarized in the first 
few pages of the report for the use of top management. 
Supporting details should be included later and in the 
appendices for other members of the organization and 
for team members who will participate in future 
follow-on activities. 

Report Preparation 

The primary writing responsibility for each of the 
sections of the report was assigned during study 
preparation. As the study progresses, changes, addi- 
tions, and deletions can be made to the preliminary 
outline. By the time the executive interviews have'been 
completed, agreement should have been reached on the 
final table of contents, and the individual study team 
members should have available to them most of the 
information needed to complete their assigned sections. 
The study team leader usually assumes the responsibil- 
ity for writing the background and overview because 
much of this material comes directly from the orienta- 
tion information presented to the team at the kickoff 
meeting. 



The conclusions, recommendations, and an action 
plan should be reviewed with the executive sponsor 
before the team drafts the final report. Controversial 
areas or areas of high impact on the business may be 
reviewed with the executive involved, to determine 
how best to present the recommendations. 

Presentation Medium 

The principal factors to consider in determining how 
the report should be presented are the type and size of 
the audience and the accepted ways of making such a 
presentation in the particular business environment. 
Consultation with the executive sponsor early in the 
study to obtain his advice on this subject can be most 
helpful in establishing the proper direction. 

If the presentation is made to a small group, easel 
flipcharts are adequate and popular. If the audience 
numbers more than a dozen, viewgraphs or slides 
should be considered. If slides are to be used, adequate 
time should be allotted to have them prepared, whether 
in-house or by an outside vendor. 

Executive Presentation 

The executive presentation can be developed complete- 
ly from material contained in the final draft of the 
report. The principal aims of this presentation are to 
inform management of the study's findings, make 
recommendations, and secure approval of the action 
plan. 

The presentation should be consise - preferably no 
longer than an hour. It should be logical and factual 
and should end with recommendations for the follow- 
on activities. For example, it may take the following 
form: 

1. Introduction 
Background and overview 
Objectives 

Scope 
Study team 

2. Study approach 
Business and i/s review 
Business processes 
Business/information systems relationships 

3. Major problem identified 

4. Conclusions and recommendations 
Information architecture and priorities 
i/s management requirements 

5. Action plan for follow-on project activities 
Description(s) 

Deliverables 
Resource requirements 
Schedules 
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Chapter 16. Overview of Follow-On Activities 



The BSP study ended with the development of an action 
plan for the follow-on activities and a presentation for 
management approval to proceed in the execution of 
that plan. This final chapter of the BSP Planning Guide 
gives an overview of the follow-on activities and serves 
three purposes: 

1 . To relate the follow-on activities to the BSP study 

2. To show how to capitalize on the results of the BSP 
study 

3. To further explain the major follow-on projects 
The following section helps in putting the follow-on 

activities in perspective and in emphasizing their 
importance. It also explains how to get the maximum 
use of the output from the BSP study. The latter part of 
this chapter attempts to give enough of an understand- 
ing of the follow-on projects to allow for scheduling 
them in the action plan and to help preparing for them. 

Perspective on Follow-on Activities 

Relation of BSP Study to Follow-on Activities 

The follow-on activities are a continuation and expan- 
sion of the major activities in the BSP study. The major 
thrust of the study was one of understanding, develop- 
ing findings and conclusions, and making recommen- 
dations. While the thrust in follow-on projects is still 
to understand, greater emphasis is put on detailed 
definitions and planning. 

There is a great need for communications among the 
project teams if project implementation is to be suc- 
cessful. Therefore, the information systems director 
should take overall responsibility for the projects, since 
the functions performed during the follow-on activities 
are a part of the ism responsibilities. Because the 
follow-on activities build upon the results of and the 
information gathered in the BSP study, there is a need 
for continuity of team members. At least one person 
on the bsp study team should have been chosen from 
the data processing function, with the idea that he 
would remain for the follow-on activities. 

The functions performed by the executive sponsor 
for the BSP study should be performed by a steering 
committee for the follow-on projects, unless there is a 
management committee that will perform them. 

Business processes continue to be the vehicle for 
understanding detailed business requirements and for 
further defining the information architecture with 
special emphasis on the definition of the first system. 

Preparation for Follow-on Activities 

Because of the variations in the findings and conclu- 
sions that may result from BSP studies, the follow-on 



activities and the emphasis placed on each of them will 
vary from one BSP study to another. For purposes of 
this discussion, the following assumptions are made: 

1. ISM functions must be changed or added to provide 
a controlled environment for the development and 
implementation of the information architecture 
identified in the bsp study. A detailed information 
systems plan will be developed that will reflect these 
planned changes. 

2. The information architecture must be further 
defined and data bases identified. 

3. A first system has been chosen for development and 
implementation. 

Orientation of Teams 

Before the beginning of each of the follow-on projects, 
the i/S director should provide orientation for project 
team members. Since many of the team members will 
not be familiar with BSP, its principles and objectives 
should be summarized. It is very important that 
everyone on the project teams understand exactly how 
the BSP study was conducted and become familiar with 
the outputs so as to be able to build upon them. 

A review of the bsp study report for the areas to be 
studied in the follow-on projects will help to determine 
whether team members need special education. A 
specification of tools and techniques may also reveal 
the need for special education. If required, appropriate 
classes can be scheduled on an individual basis. If the 
i/S director was not a member of the BSP study team, it 
might be advisable for him to attend the IBM Informa- 
tion Systems Planning course. 

The following is a sample list of topics for project 
team orientation: 

Introduction by the sponsor 
Objectives of the orientation 
Information systems concepts and perspectives 
Data base concepts 

Overview of the BSP study methodology 
Detailed discussion of the bsp study 
Business environment 
Objectives 

Major processes identified 
Major problems 

Current I/S support for the business 
Interviews 

Information architecture 
Major findings and conclusions 
Recommendations 
Introduction to the follow-on activities 
Relation to the BSP study 
Relation to the BSP study deliverables 
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Discussion of deliverables from the follow-on 

activities 

Explanation of follow-on projects 

Introduction of tools and techniques 

Introduction of preparation activities 

Activities already performed 

Activities to be performed by team members 
Interviewing strategies and selection of interviewees 
Use of matrices 

Pilots of forms, tools, techniques and interviews 
Introduction to HIPO and its use in the follow-on 
projects 

Assignment of responsibilities 
Development of task descriptions by team members 
Explanation of project control systems 

Information Systems Management 

ISM is the keystone of effective support of the business 
by information systems. It can be defined as the 
management of the information systems resources for 
the most efficient and effective support of the business. 
The importance of continual emphasis on ISM is 
summarized by the following statements: 

• Development of the information architecture will 
take place over a period of years. 

• Changes to business strategies and plans as well as 
I/S technology will be continual during the develop- 
ment of the information architecture. 

• The processes of managing i/s will have to be 
refined and changed continually to properly plan, 
measure, and control required i/S resources. 

• The BSP study is a one-time effort that should be 
followed by continual i/S planning to fully capitalize 
on the results. 

ISM in Perspective 

As covered in Chapter 13, the ISM follow-on projects 
will emanate from (1) requirements to support l/s 
objectives, (2) changes resulting from the development 
and implementation of the first system, and (3) recom- 
mended changes to solve i/s support problems and ISM 
problems. 

From this it is safe to assume that the recommenda- 
tions included: 

1 . Emphasis on information systems planning and 
control and on data administration. 

2. Some close-in projects, such as the establishment of 
a steering committee and refinements to project 
control. Capacity planning is also a natural follow- 
on to a BSP study since it examines the data process- 
ing capacity and determines whether changes are 
required to accommodate the architectural priorities 
or to solve some of the l/s support problems. 

3. A major project(s) in ism, e.g., establishing an action 
plan to move to distributed data processing. 



Perhaps the most important action to be taken after 
the BSP study is to decide what person or group of 
persons is responsible for continuing the I/S planning 
using the BSP study as a base. While the BSP study 
culminated in an approved action plan, the overall 
objective of an ISM project will be to develop a long- 
range i/s plan that will direct the design, development, 
and implementation of an information architecture. It 
should include sufficient detail on projects, resources, 
and schedules to guide all levels of management on 
what is to be done, when, and by whom in the organi- 
zation. Since the long-range i/s plan is an integral part 
of the business plan and is prepared with full manage- 
ment involvement, it should help to provide that the i/S 
resources of the business will be used to effectively 
support the business. 

Also, since data management is a complex area 
requiring long lead times, the data administrator 
should be decided upon as early as possible so that this 
function can be properly coordinated. 

The importance of I/S planning and data adminis- 
tration cannot be overemphasized, and they will nearly 
always be a part of the follow-on activity. The activi- 
ties will not be explained further here since they are 
covered thoroughly in IBM, GUIDE, SHARE, and trade 
publications. 

Some of the close-in projects should be done 
immediately after the bsp study recommendations are 
approved and before most of the follow-on activities 
are started. The establishment of a steering committee 
and a project control system are excellent examples 
since a steering committee should be available to direct 
the follow-on activities and a project control system 
should be in place to help the I/S director adequately 
control and coordinate the activities. 

The major ism follow-on project will probably be a 
long-range activity such as i/s planning or data admin- 
istration or a combination of both. 

Because of the size of these projects and their 
interactions with all the I/S processes, it is important to 
fully understand all the functions of ISM before under- 
taking any recommended change to any part of ISM, 
just as it was important to fully understand the busi- 
ness before starting to fulfill the information require- 
ments. Some mechanism should exist to get the broad 
view of ISM, and BSP can be used as that mechanism. 
You may treat l/s as a business-within-a-business and 
apply to it the same BSP techniques that you have 
applied to the business in which it is located. 

Information Systems as a Business 

Many of the activities for performing a BSP study in the 
i/S function have already been accomplished: 
• Facts relating to information systems were gathered 
as part of the study preparation phase. 
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• ISM responsibilities, activities, and problems were 
identified by the I/S director during the kickoff. 

• Many of the findings and conclusions have already 
been put together as a result of examining the i/S 
facts and the problems. 

• A first ism project has been identified and an action 
plan established. 

While some of these activities will have to be 
expanded, they make a significant start in understand- 
ing the whole I/S function. The following identifies 
other steps that should be performed: 

1. Defining ISM processes. Appendix I suggests the 
processes that take place in ISM. This may be used 
as a checklist to identify the ISM processes. Other- 
wise, you may wish to identify the information 
systems resources and the activities and decisions 
found in their management cycle. The following is a 
list of resources to be considered: 

Programs and systems 

Functional modules 

Data bases 

Hardware/software/communications facilities 

User facilities (terminals, languages, data bases, etc.) 

Physical facilities 

Finance 

People 

2. Analyzing relationships of organization, processes, 
information systems, and data. This is an exact 
parallel to the development of the matrices to show 
relationships in the business BSP study, except that 
the information systems are those that support the 
I/S functions, such as equipment utilization systems 
and chargeout systems. The data is that needed to 
support these and other systems used to manage the 
I/S function. 

3. Interviewing. The interviewing in ISM will normally 
be with the upper two levels of information systems 
managers, selective interactive users, the executive 
to whom the I/S director reports, and selected 
functional users. 

The remaining steps are the same as the BSP metho- 
dology for the business and should be conducted by a 
small team led by the individual responsible for i/S 
planning or another person with a broad responsibility 
in i/s. 

The BSP study of the I/S function may be done as 
part of the ISM follow-on project, as suggested. It 
should also be considered as an effort that can be made 
either concurrently with the business BSP study, before 
it, or immediately after it and before the start of any 
follow-on projects. 

As an activity before the business study, the I/S 
study provides experience in the methodology, offers 
an excellent view of I/S as input to the business study, 
allows an early start on ISM projects, and can serve as a 



selling tool if some executives are skeptical of the 
methodology. It must be recognized that a major 
deficiency exists in the understanding of part of the I/S 
environment, which in this case is the rest of the 
business. 

BSP is so demanding of a team's time that running 
the two studies concurrently will require two teams, 
closely coordinated. The added emphasis on ism may 
detract from the major goal of understanding the 
business and may give the entire study a much greater 
flavor of an I/S project than is desired. The major 
advantage is the ability to relate I/S problems directly 
to ISM problems and make sound recommendations on 
ISM in the action plan and report of the business BSP 
study. 

Ideally, the i/S study should be done immediately 
after the business study, since (1) the required inputs 
are readily available, (2) the momentum will carry over 
from the business study, and (3) the best environment 
will exist for conducting all the follow-on activities. 

Information Architecture 

The amount of follow-on effort required in the archi- 
tecture area depends on the level of detail in the BSP 
study. If the information architecture was not com- 
pletely defined as outlined in Chapter 1 1, the basic 
architecture definition should be completed as the 
beginning of a follow-on project. 

The architecture refinement to be accomplished in a 
follow-on project should include a confirmation of the 
major i/S groupings, the subsystem breakout of each 
system, subsystem interrelation, and data flow among 
subsystems. 

Several other activities should be included in the 
information architecture project: 

• Examination of current data processing systems to 
determine how they can evolve (provided they can 
at all) into the new systems architecture 

• Establishment of a continuing link between the 
architecture and the business plan to ensure that the 
I/S plan will be based upon a viable information 
architecture 

• Documentation of alternative architectures that 
were tried or investigated and rejected, with the 
reasons for rejection 

• Evaluation of the technical implications of the 
information architecture, including control systems, 
db/dc requirements, and potential distribution of 
both information and systems 

Architecture Refinement 

Using the information architecture defined in the BSP 
study, a description of each subsystem should be 
prepared. Each description should include the purpose 
of the subsystem, business problems addressed, data 
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created and used, dependencies on other subsystems, 
general requirements for implementation, and priority 
of the subsystem with respect to all other subsystems. 

Current Systems Examination 

For data processing systems currently in use or under 
development, a careful examination should be con- 
ducted to determine how each one relates to the 
subsystems described in the information architecture. 
Possible modifications to current systems should be 
documented with respect to interfacing them to the 
future architecture. Where modified systems could be 
used in lieu of new subsystems, a description should b»e 
included in the architecture documentation. For 
systems already under development, an evaluation 
should be made of possible modifications to make the 
developing system compatible with the new informa- 
tion architecture. Analysis should be made of the 
impact on current development schedules versus the 
avoidance of modifying the system after implementa- 
tion, keeping in mind present commitments and future 
priorities. 

Data Base 

Integral to information architecture definition in the 
BSP study were the data classes supporting the business 
processes. A logical grouping of related data classes 
will yield the set of data bases that will support the 
architecture implementation. 

A data base can be defined as a nonredundant 
collection of interrelated data items processable by one 
or more applications. Some of the terms in the defini- 
tion itself may need explaining: 

• Nonredundant means that individual data items 
appear only once (or at least less frequently than in 
normal file organizations) in the data base. 

• Interrelated means that the files are constructed with 
an ordered and planned relationship that allows 
data elements to be tied together, even though they 
may not necessarily be in the same physical record. 

• Processable by one or more applications means 
simply that data is shared and used by several 
different subsystems. 

Development of a data base has some obvious 
benefits. By consolidating files, the user can obtain 
better control of data and reduce storage space and 
processing time. Equally important are the resultant 
data synchronization and timeliness. Use of a single 
information source makes processing more accurate 
because all subsystems refer to the same data. 

A data base system can help overcome some of the 
complexities of data management. It can provide 
additional data relationships while minimizing storage 
redundancy. Figure 38 illustrates how a data base 



system can support subsystem needs independently and 
currently. 

A comparison of the data base environment with the 
traditional approach to systems development and 
maintenance reveals the advantages of the data base 
concept. In the traditional approach, a system is 
usually designed, programmed, tested, and then 
implemented as a total entity. Its advantages cannot be 
realized by the end user until the entire system is 
completed. The amount of time involved can cause 
frustration, since business requirements cannot be kept 
frozen long enough to avoid changes, delays, and false 
starts. Also, when data or logic changes are required, 
considerable testing may be necessary to determine 
how the change affects other programs or systems 
functions. 

By contrast, the data base approach allows a gradual 
transition from existing systems to online, transaction- 
driven systems. The data base is created gradually, 
with just a few transactions implemented at a time. 
Current data base techniques facilitate this type of data 
base and system implementation. With gradual 
implementation of transactions, user department 
signoff can be obtained more easily and the user can 
enjoy the benefits earlier. This approach also helps 
overcome the problem of not being able to freeze 
business requirements and technological advances 
during Jthe development cycle. Changes that must be 
made along the way impact individual transactions or 
become new transactions themselves. Changing data 
needs can be accommodated without affecting pro- 
grams that do not use that specific area or segment of 
the data base. Thus, the data base environment can be 
a better way to accommodate change, deliver benefits 
to the user, and control development costs. 

Distributed Information Systems 

The general purpose of distributed information systems 
is to provide the user with a level of computing re- 
source best suited to his operational requirements. The 
elements that can be considered for distribution 
include hardware, program execution, program 
development, and data. Degree of distribution can 
vary from totally centralized to totally decentralized. 
The information architecture defined in the BSP study 
can provide a good foundation for the additional 
planning necessary to address I/S distribution require- 
ments. 

If the information architecture follow-on project is 
to add distributed i/S parameters to the architecture, 
the project team must: 

• Thoroughly understand the degree of distribution of 
each element 

• Understand the arguments for and against distribu- 
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tion of the various elements 

• Be able to put into perspective all the factors that 
affect distribution and sharing of data processing 
resources 

• Appreciate the need for a long-range i/s plan and 
for development of a facilities plan to support the I/S 
plan f 

Several of the matrices developed in the BSP study 
can be very useful in developing the architecture 
extensions with respect to distribution. The process 
and data flow analysis should be extended to include 
physical locations for systems and data requirements. 
Location/organization, location/process and 
location/data matrices should be prepared. A 
process/data matrix for each location (or group of 
similar locations) should be prepared with additional 
parameters on the axes to include data use, security, 
auditability, data occurrence (all or partial), activity 
volumes, response required, and criticality\ Figure 39 
shows this type of matrix for a manufacturing plant 
site. 

These additions to the architectural description of 
the information systems can then be input to the 
individual subsystem requirement studies tb determine 
detail distributed systems requirements. They will also 
give an overall feel for the applicability of distributed 
systems to the information architecture. 

Developing the First System 

The BSP team has recommended that a particular 
high-priority system be developed and implemented 
first. As development of that system begins, care 
should be taken that this system is not developed "by 
itself." The BSP study has set a certain direction for 
implementation of systems. This first development and 
implementation must support the business processes 
and must: 

1 . Fit properly into and interface with the other 
(future) systems of the overall architecture described 
in the BSP study 

2. Provide for proper implementation of the appropri- 
ate data base(s) 

As described in the ISM section of this chapter, these 
concurrent projects must be carefully managed (ISM) to 
ensure that they lead toward an integrated whole rather 
than perpetuate "separatist" or "standalone" applica- 
tions development. 

System development is a complex process. It 
requires technical expertise, effective communications, 
and skillful handling of conflicting objectives of users, 
management, and data processing. 

Technical Factors 

There is no doubt that developing information systems 
is more complex today than in the past. Factors such 



as data security, data integrity, data communications, 
rapid availability of large amounts of data, and backup 
and recovery requirements complicate the tasks that 
must be performed on a project. They also add to 
requirements for skilled personnel to perform such 
tasks. 

In many areas technical risks may be reduced by 
incorporating appropriate hardware/software products, 
productivity techniques, and procedures. An invest- 
ment of time in evaluating existing products and 
applying them to the recommended system will reap 
ample rewards in a better system implementation. 

Effective Communication 

Effective communication is indispensable to successful 
system development, which entails the communication 
and translation of management and user business 
requirements into achievable data processing solutions. 

Only users can determine the business requirements 
of the system to be developed. Their involvement and 
continued participation are, therefore, essential. 

Developers sometimes try to second-guess the needs 
of users and to create systems they believe will do the 
job. More often than not, this approach is unsatisfacto- 
ry. While the technical aspects of such a system may be 
sound, the real business needs of the organization may 
not be addressed or met. 

Users and developers need a mutual understanding 
of what is to be done and a commitment to their 
respective responsibilities. The development process 
itself must ensure communication and commitment 
between the two groups. 

Communications may be greatly facilitated by the 
use of standardized documentation techniques such as 
HIPO, structured walk-throughs, and the like. These 
not only reduce misunderstandings but contribute to 
increased productivity, which in turn should speed up 
implementation of the system or application. Where 
appropriate, such aids should be evaluated, adopted, 
and incorporated in the development project. 

Priorities and Conflicts 

The need to set priorities for conflicting objectives is 
crucial. Conflicts can make even simple situations 
complex and can cause many serious project difficul- 
ties. 

Even before a project is under way, the new system 
must compete with the demands of trained personnel to 
maintain old systems. Application development 
resources are in short supply, and experienced develop- 
ment skills may be hard to find because everybody has 
a backlog of applications waiting to be developed. 

The project manager, therefore, must be qualified 
both in project management techniques and in the 
business area to be supported by the first system. 
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Figure 39. Distributed information requirements analysis 
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Ample education, documentation, and products are The project manager and appropriate team mem- 
available for both. A thorough analysis of support bers should be thoroughly prepared in these areas 
should be made and a technical support plan should be before the start of the project. This should result in 
put together to utilize the education, documentation, effective project management, which in turn will 
and products wherever possible. You should work reduce risks and optimize the business value of the first 
with your IBM marketing representative to develop implementation, 
such a plan. 
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Appendix A. Sample Executive Announcement Letter 



To: All executives 

Subject: Business Systems Planning Study 

I am sure all of you are aware of the dynamic nature of 
our business. Our success in the future will depend 
greatly on how we plan and react to the business envi- 
ronment. I am pleased to inform you that we are initiat- 
ing a major effort to analyze our current and future in- 
formation needs. I have authorized a study group that 
will conduct an in-depth study on how we use information 
and its relation to our business. 

The study project will be directed by Ms. Marilyn Jordan, 
with other company personnel involved on both a full-time 
and part-time basis. Assisting us in an advisory capacity 
will be personnel from the IBM Corporation. We will be 
using a methodology called Business Systems Planning 
(BSP), which has been helpful to other companies in eval- 
uating and planning for their information requirements. 

Key to the study's success is the precise identification 
and clear statement of our individual and collective in- 
formation needs. To this end, the study team will want to 
discuss our information needs with us in detail in a series 
of individual interviews. It is essential that each in- 
dividual who is asked to participate in an interview be com- 
pletely candid in discussing problems, needs, and plans with 
the team members. You will be contacted by Ms. Jordan in 
the near future to set up interview dates and times. I urge 
you to give full cooperation in this valuable enterprise and 
work as closely and cooperatively with the study group as 
possible. 

I am confident the study will be of tremendous value to the 
company and help us accomplish our overall objectives. 

Sincerely, 



Edward J. Bissel 
President 

EJB/rth 
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Appendix B. Sample Interview Confirmation Letter 



To: Mr. H.R. Zimmer 

Vice President of Planning 

Subject: Business Systems Planning Study 

Mr. Bissell's recent memorandum announced the initiation of an in- 
depth information systems planning study for our business. The 
objectives of the study team are to: 

• Develop an overall understanding of the business 

• Understand how information systems currently supports the business 

• Identify an information architecture that will support the business 

• Identify the first or most needed subsystems within the network 

• Make recommendations for improvements 

• Develop an action plan 

To assist the study team in this effort, we intend to interview the 
key executives of our business. Each interview is estimated to take 
2-k hours. I have Wednesday, April 9, at 1:00 p.m. scheduled on 
your calendar for me and other selected members of the BSP team to 
meet with you. The meeting will be in the former EDP office at the 
south end of Building 2. 

The purpose of the meeting is for us to learn about your area of 
responsibility, the information you consider essential to manage 
your area, and the problems you currently have in obtaining this 
needed information. The discussion of these topics will enable us 
to better understand your information needs to evaluate the current 
information systems, and to define systems that are responsive to 
your information needs. Attached is a list of topics we wish to 
discuss with you. 

If you have any questions before our meeting on April 9, please call 
me. Thank you for your cooperation. 

Sincerely, 



M.C. Jordan, BSP Study Team Leader 
Attachment 
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Appendix C. Examples of Process Groups and Processes by Industry 



Insurance 

Management Planning 

Corporate direction planning 

Long-range planning 

Business planning 

Acquisition/ventures planning 
Product Management 

Managing the book of business 

Product service monitoring 

Product reevaluation 
Control and Measurement 

Financial planning 

Operational planning 

Performance evaluation 
Product Development and Maintenance 

Product design 

Pricing 

Product goals and measurement 

Product implementation 
Facilities, Equipment and Supplies 

Facility planning 

Facility services management 

Equipment and supplies management 

Warehousing and distribution 
Merchandising 

Lead development 

Selling 

Customer qualification 

Risk engineering 

Establishing and maintaining customer record 

Billing and collections 

Customer servicing 
Product Service 

Insurance 

Insurance claim evaluation and disposition 

Non-insurance processing service 

Non-insurance professional service 
Financial 

Cash management 

Asset accounting 

Expense allocation 

Claim reserves 

Tax processing 

Corporate books and ledgers admin. 

Investment management 
Administration 

Legal services 

External relations 

Advertising 

Auditing 

Information development 

Operational support 



Manpower management 

External services management 

Systems planning 

System development/maintenance and operations 

Finance 

Management Planning and Control 

Objectives planning 

Forecasting alternatives 

Measurement and control 

Organization 

Policy setting 

Resource allocation 

External relations 
Product Development 

Review and approval 

Resource evaluation 

Strategy development 

Education development 

Pricing 
Marketing 

Market definition 

Market research 

Advertising and promotion 

Public relations 

Product implementation 

Competitive analysis 
Money Management 

Investment management 

Money market instruments 
Customer 

Investigation and acceptance 

Account establishment 

Account control 

Account maintenance 

Account termination 
Funds Transfer Services 

Letter of credit 

Money transfer 

Bond transfer 

Stock transfer 

Loan 

Deposit/withdrawal checking 

Collections 

Lock box 

Automatic dividend reinvestment 

Foreign exchange 

Cash management 
Trust 

Accounting services 

Asset management 
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Operations 

Communications 

Data processing 

Transaction servicing 

Inquiry servicing 

Corrections 

Mail 
Finance 

Budget planning and control 

Financial analysis 

Asset management 

Liability management 

Capital management 

Financial reporting 
Personnel 

Planning 

Recruiting and hiring 

Training 

Wage and salary administration 

Employee relations 

Benefits management 

Career development 

Retirement or separation 

Government compliance 
Legal 

Litigation 

Tax consequence advising 

Contracts review 

Legislation impact analysis 

Legal compliance review 
Administration 

Accounting 

Audit 

Facilities 

Regulatory compliance 

Taxes 

Payroll 

Security 

Process (Chemical) 

Planning 

Strategic planning 

Market research 

Technical feasibility 

Economic analysis 

Forecasting 

Resource requirements 
Product Development 

Exploration 

Engineering development 

Licensing 

Engineering design 

Construction 
Marketing 

Sales forecasting 



Advertising/promotion 

Pricing 

Selling/contracting 

Order entry 

Customer service 

Sales analysis 
Manufacturing 

Production forecasting 

Scheduling 

Inventory 

Plant operations 

Packaging 

Warehousing 

Shipping 

Maintenance 

Quality control 

Product cost control 
Distribution 

Carrier and rate negotiations 

Supply /demand planning 

Order processing 

Rating and routing 

Terminal operations 

Warehouse planning/operations 

Fleet planning 

Fleet operations 

Inventory control 
Financial 

Financial planning 

Financial analysis 

Capital transaction and control 

Budgeting 

General accounting 

Cost accounting 

Taxes 

Government report 

Payroll 
Administration 

Personnel development 

Salary and benefits administration 

Labor and personnel relations 

External affairs 

Legal 

Insurance 

Information services 

Facilities services 

Process (Paper) 

Product Development 

Product design 
Raw material requirements 
Facility planning 
Market forecast 
Financial requirements 
Market planning 
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Marketing 

Sales planning 

Product plan 

Sales analysis 

Order entry 

Customer services 

Pricing 
Production 

Requirement planning 

Production scheduling 

Raw material planning 

Receiving 

Production reporting 

Quality control 

Inventory 

Shipping 

Maintenance 
Engineering Support 

Project engineering 

Environment 

Energy requirements 

Standards 

Material handling 
Financial 

Cash management 

Budgeting 

Capital expenditures 

Cost analysis 

Financial reporting 

Payroll 

Customer billing 

Accounts receivable and payable 

Audit 
Administration 

Purchasing 

Personnel services 

Traffic 

Salary administration 

Information services 

Legal 

Stockholder relations 

Public affairs 
Industry Relations 

Labor relations 

Personnel development 

Safety 

Manufacturing 

Product Development and Application 

Technology development 
Product application 
New product 
Old product 
Application engineering 
Specifications 



Drafting and records 

Product performance 
Product Planning 

Determination of business case 

Evaluation of business case 
Marketing 

Marketing planning 

Market research, market development 

Pricing 

Publications, advertising, promotions 

Sales analysis and forecasting 

Warranty policy and other software 

Market operations 

Distribution network 

Field sales and service 

OEM sales and service 

Order entry 
Financial Management 

Funds management 

Cash 

Short-term financing 

Long-term financing 

Financial control 

Budget/expense 

Managerial accounting 

General accounting 

Bookkeeping 

Internal control 
Administration 

Legal 

Public relations 

Security 

Governmental reporting 

Office management 
Planning, Control and Measurement 

Fiscal year business plan 

Annual operating plan 

Quarterly operating plan 

Reporting and control 
Personnel Management 

Planning 

Acquiring 

Development and administration 

Reporting 

Termination 
Operations Control 

Master production plan 

Transportation planning 

Performance reporting 

Inventory control 
Capacity Management 

Determination of optimum capacity 

Capacity allocation 

Acquisition of capacity 
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Material Acquisition 

Vendor evaluation 
Order control 
Receiving and inspection 
Plant Operations 

Planning, schedule and control 

Performance reporting 

Expediting 

Planning of material, manpower 

Order processing - plant order boards 

Product and process specifications 

Execution 

Order release 

Dispatching 

Storage/warehousing 

Quality 

Preventive maintenance 

Material transfer - to/from supplier/customer 



Distribution 

Buying 

Vendor selection 

Requirements 

When to buy 

Allocation 

Sales planning 

Inventory control 

Pricing 

Markdowns 
Selling 

Presentation 

Display 

Manpower planning 

New item introduction 

Advertising 

Customer service 
General Operations 

Purchasing 

Facilities maintenance 

Security 

Public relations 

Audit- 
Inventory control 

Physical inventory control 

Internal communications 

Facilities development 
Management and Financial Control 

Budgets 

Cash management 

Profit planning 

Measurement and control 

Capital expenditure planning 

Credit granting 



Financial negotiation 
New business 
Administration 
Accounts payable 
Accounts receivable 
Payroll 

Statistical and financial reporting 
Audit 

Merchandise processing 
Personnel/training 

Government 

Judicial 

Prosecution 

Defense 

Court procedures 

Control 

Civil 
Public Facilities 

Definition 

Construction 

Maintenance 

Property management 
Public Protection Process 

Enforcement 

Confinement 

Rehabilitation 

Prevention 

Inspection 
Finance 

Taxing 

Licensing 

Accounting 

Collections 

Funds management 

Payroll 

Purchasing 
Personnel 

Recruiting/hiring/terminating 

Career development 

Job classification 

Labor relations 

Compensation and benefits 

Employee/position management 
Management 

Conflict 

Measurement and control 

Policy determination 

Budgeting 

Security/privacy 

External relations 

Recordkeeping 
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Community Service 

Library 

Public records 

Election administration 

Cultural and recreational support 

Environmental control 
Public Aid Process 

Eligibility determination 

Financial assistance 

Manpower 

Social services 

Residential care 
Health Services 

Admissions 

Inpatient care 

Outpatient care 

Education and research 

Emergency care 

Community health services 

Education - University 

Student 

Promotion/recruiting 

Evaluation and admissions 

Class registration 

Academic and career advising 

Financial aid 

Student activities/life 

Student services 

Student status/archives 
Credit Instruction 

Curriculum development 

Scheduling instructional resources 

Teaching and learning 

Evaluation and measurement 
Research and Artistic Creativity 

Project identification and definition 

Procurement of resources 

Project execution 

Evaluation 

Dissemination of results 
Public Services and Extension 

Activity development 

Administrative and logistical services for clientele 

Resource procurement and organization 

Activity delivery 

Activity evaluation 



Financial Management 

Income acquisition 

Stewardship of funds 

Receipting and disbursement of funds 

Cash management 

Protection against financial liabilities 

Financial services 

Financial recordkeeping 
Personnel 

Recruiting 

Hiring/termination 

Career development and evaluation 

Salary and benefit administration 

Employee relations 

Assignment of responsibilities 

Job classification 

Recordkeeping 
Institutional Planning and Management 

Goals development 

Strategic planning (long-term) 

Tactical planning (short-term) 

Allocation of resources 

Monitor and control 

Internal communications 
Physical Plant Management 

Program statement 

Design 

Construction and procurement 

Maintenance/operation 

Disposition 

Protection 

Rental property management 
Goods and Services 

Assessment of needs 

Acquisition 

Inventory of expendables 

Inventory of non-expendables 

Distribution 
Alumni Affairs 

Tracking 

Programs and services 

Institutional evaluation 
External Communication and Relations 

Publicity 

Negotiation 

Public service 

Extra-university affiliation " 
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Appendix D. Examples of Planning and Control Processes 



Cyclical Planning and Control 

Five-Year Business Planning 

Establishment of a long-range business plan, taking 
into consideration such things as product, product 
demand, capacity, manpower, financial strategies, and 
information systems to achieve company goals. 

Annual Operation Planning 

Development of a medium-range operating directive to 
control the business activities in achieving the five-year 
business plan. 

Quarterly Operation Planning 

Quarterly restatement of annual operating plan, 
reflecting a 'firm' operating plan for three months and 
a 'forecasted' operating plan for the following three 
months. 

Reporting and Control 

Review of the performance of operating units to ensure 
the success of the plans. Change directions of operat- 
ing units and/or plans when necessary to meet the 
objectives of the company. 

Product Planning and Development 

Technology Development 

Includes applied research on new engines, combustion 
systems, material, etc., and basic research on new 
power systems. 

Product Application 

Application of research results to existing product line 

and new products. 

New Product - Development, testing and release of 
new products (components, engines or "software"). 
Old Product - Application of improvements to 
existing products. 

Application Engineering - Applying the basic engine 
to different customer applications (requirements). 
Specifications - The process of developing and 
recording standard company specifications for 
products, material, inspection, process, supplier 
certification, etc. 

Drafting and Records - Production of drawings that 
describe the product, its characteristics, and its 
applications. 

Product Performance 

Tracking and measuring the performance of an engine 



from the test cell through the field use; includes 
measuring warranty exposure and cost along with 
failure rates. 

Capacity Planning 

The determination of production and test capacity 
required to meet the planned production volume, 
allocation of this within the company and supplier 
facilities, and acquisition of any additional capacity. 

Determination of Optimum Capacity 

Required productive and test capacity is determined on 
the basis of the planned production volume. 

Capacity Allocation 

The assignment of productive and test capacity among 
the company and supplier plants. Make-vs-buy 
analyses are made to determine internal and external 
(supplier) requirements. 

Market Planning and Strategies 

Market Research, Market Development 

Identify markets, lay plans, and set strategies for 
penetrating those markets. 

Pricing 

Establish as part of market penetration and product 
planning strategies. 

Publications, Advertising, Promotion 

Support and augment strategies and tactics of market 
development. 

Sales Analysis and Forecasting 

Provide necessary information to plan and measure 
strategies and tactics. 

Warranty, Policy and Other "Software" 

Establish as integral with strategies and tactics of 
market penetration. 

Personnel Planning 

Policies 

The establishment and implementation of policies and 
practices concerning employment, development, 
compensation and evaluation of employees. 
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Requirements 

Determination of manpower requirements in line with 
business objectives. 

Financial Control 

Establish, coordinate, and administer, as an integral 
part of management, an adequate plan for the control 
of operations. 

Budget/Expense 

Provide expense budgets and cost standards together 
with the necessary procedures to effectuate the plan. 

Managerial Accounting 

Compare the results of operations with plans and 
standards; interpret them for all management levels. 

Operations Control 

Development of a sourcing plan with and between the 
plants, the review of delivery performance, and correc- 
tive action necessary to accomplish the business 
commitments. 

Master Production Planning 

Translation of a central order board into a coordinated 
production plan and placing requirements in plants at 
a meaningful part level. 

Transportation Planning 

Determination of transportation strategies and capabil- 
ities necessary to support the operations plan. 



Performance Reporting 

The process of feeding back information on actual 
production against the master production plan on a 
periodic basis, and provision of input for any required 
modification of plans and schedules. 

Inventory Control 

Determination and control of the levels of inventory 
required to meet a predetermined level of production 
and service, with the objective of minimizing the 
overall cost. 

Plant Operations 

The process of producing products or parts according 
to a given schedule and specifications in the most 
efficient manner. 

Planning, Scheduling and Control 

Determination of quantities to be produced on a daily 
basis and the corrective action taken if necessary. 
Performance Reporting - Communicating the 
quantities produced in a given time. 
Expediting - Short-term replanning as required. 
Planning of material, manpower, and optimum use of 
equipment 

Order Processing - The process of maintaining a 
plant order board of all products to be shipped, 
including finished engines, components, kits and 
service parts, both to customers and other plants. 
Product and Process Specification - Maintenance of 
records regarding product definition and the incor- 
poration of engineering changes. 
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Appendix E. Sample Descriptions of Processes 



Market Process 

The activities necessary to identify and satisfy the 
wants and needs of chosen customers at a profit. 

Marketing Planning 

Setting marketing objectives and strategies to support 

overall company objectives. 

Inventory Levels - Determining raw material and 
finished goods inventory levels to meet profit 
objectives and supply the customers' needs. 

Marketing Research 

Systematic, objective, detailed search for and study of 
facts and information relevant to any marketing 
problem or opportunity. 

Consumer Research - Measurement and interpreta- 
tion of consumer attitudes. 

Product Research - Securing facts relating to desired 
product characteristics; the measurement and 
evaluation of product sales potential. 
Sales Research - Measurement and evaluation of the 
company's sales potential by geographic area. 

Merchandising 

A creative activity having as its purpose the develop- 
ment of the products necessary to meet predetermined 
profit, volume and "niche" objectives. 

Product Development - Styling, i.e., the mating of 
distinctive aspects of a product to appropriate 
materials and trim from selected sources; determin- 
ing the proper fold, package and labeling of the 
finished product. 

Pricing - Matching manufacturer's cost to customer 
requirements. Includes preliminary costing. 
Price Lining - Building the proper depth at each 
price point. 

Forecasting - Sales forecasting and reforecasting. 
Quality level - The intrinsic value level of product 
agreed upon between buyer and seller. 

Advertising and Promotion 

The activity that communicates the need-satisfying 
benefit of the product to potential consumers. 

Sales Promotion - Those methods used to create 

customer traffic at the retail level. 

Sales 

Matching customer needs to products. 

Selling - Coordinates with Advertising and Promo- 
tion, Distribution, Inventory Levels, and Production 
Planning. 



Customer Service 

Activities of service and support to communicate to the 
buyer and to the stores the status of all products at all 
times. This includes the traditional concept of order 
entry and order allocation. This is a service to buyers 
which provides actionable trade information. 

Customer Service/Retailing 

Use of credit cards, refunds made at retail stores, 
customer complaints. 

Distribution Process 

Activities required to move finished products to 
customers on time. 

Receiving 

The act of identifying, counting, verifying, and inspect- 
ing finished products. 

Inspection - The determination and classification of 
the quality of finished goods. 
Returns - The handling of finished products re- 
turned from a customer, the determination of action 
necessary, and the return of goods to inventories. 

Storing 

The safeguarding, recounting and internal handling of 
finished products to ensure accountability for location 
and cycle inventory checks. 

Packing and Repacking - An activity that results in a 

recombination of units or styles into a 

shipping/order unit. 

Marking - The affixing of identifying information 

and/or price to an individual unit of finished 

product. 

Inventorying - The counting of units of individual 

products for comparison to recorded quantities. 

Liquidating - Sale of obsolete finished goods. 

Shipping 

The activity of moving stock to a customer on time. 
Documentation - The recording and recordkeeping 
relative to the picking, packing, and shipping of 
customer orders. 

Traffic - The determination of routing and carriers 
for customer shipment. 

Vehicles - The scheduling and maintenance of 
company-owned or leased trucks. 

Unique Retailing Operations 

The activities related to the distribution of supplemen- 
tal finished products to a customer. 
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Stock Replenishment - The acquisition and distribu- 
tion of finished products in relation to units of stock 
sold. 

Point of Sale - The collection and analysis of 
statistics concerning actual unit sales. 

Personnel Process 

Development and administration of policies and 
programs to attract, develop and hold qualified em- 
ployees and ensure their equitable treatment and 
advancement to their highest level of competence. 

Manpower Planning and Development 

Planning, selecting, educating, and training the man- 
power required to accomplish the company's objec- 
tives. 

Affirmative Action - Development and administra- 
tion of policies, procedures and programs that result 
in hiring, rewarding, and promoting qualified 
minorities. 

Manpower Planning - Determination of the quanti- 
tative and qualitative manpower requirements of the 
organization and the development and administra- 
tion of programs to acquire and/or develop the 
manpower needed. 

Recruitment and Selection - Searching out, evaluat- 
ing and selecting employees to meet the specified 
requirements and accomplish company objectives. 
Education and Training - Aiding in the determina- 
tion of the education and training needs of employ- 
ees and arranging for the development and conduct 
of such education and training. 
Manpower Development - Aiding in the determina- 
tion of the personal development needs of individual 
employees, and in the planning of ways and means 
to provide that development in order that each 
employee is aided in achieving his highest level of 
competence. 

Employee Compensation and Benefits 

Development and administration of policies, proce- 
dures and programs designed to attract and hold 
employees and to reward them equitably according to 
the quality of their work, by means of salaries, wages, 
benefits, etc. 

Employee Attitudes/Relations 

Development and administration of policies, proce- 
dures and programs to develop and maintain a high 
state of employee morale and productivity, and to 
monitor that activity and recommend action as neces- 
sary to accomplish objectives. 

Employee Morale - Development and administra- 
tion of programs to monitor employee morale and to 
recommend action to maintain a motivated, pro- 



ductive, satisfied work force; to commit to employ- 
ees only what has been approved and then to follow 
up on any commitments made. 
Communications - Developing and administering 
policies, procedures and programs to keep employ- 
ees well informed on things they need to know to 
perform their work, and to promote positive atti- 
tudes and job satisfaction. 

Separation/ Retirement - Development and adminis- 
tration of policies, procedures and programs pertain- 
ing to the separation and retirement of employees. 

Employee Safety and Health 

Establishing and administering policies and programs 
to protect the safety and health of all employees. 

Financial Process 

The activities involved in the acquisition and manage- 
ment of the fiscal resources of the company. 

Financial Planning 

The process of setting financial objectives and strate- 
gies to support overall company objectives. 

Cash Requirements Forecasting - Determining total 

cash needs by period, on the basis of annual plans, 

and weekly accounting unit needs. 

Capital Requirements Forecasting - Reviewing 

long-term needs for capital and leased equipment, 

on the basis of annual plans. 

Profitability Analysis Forecasting - Predicting 

profitability trends by units, on the basis of annual 

plans and historical information. 

Funds Acquisition and Management 

The process of securing the funds necessary to run the 

company. 

Capital Structure - Determining the source of funds 
such as retained earnings, sale of stock, short-term 
borrowing, long-term debt, lease obligations. 
Banking Relationships - Developing avenues of 
short-term capital to satisfy cyclical requirements; 
establishing deposit banks to speed up cash collec- 
tion. 

Investment Community Relationships - Supplying 
information to financial analysts to develop sources 
of long-term borrowing, improving performance of 
stock, and meeting SEC requirements. 

Financial Operations 

The process of controlling the assets of the company. 
Tax Accounting - Filing appropriate tax returns, 
optimizing savings whenever possible. 
Government Reporting - Filing appropriate forms for 
use of agencies as required by law. 
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Budgets - Preparing period plans with the assistance 
of marketing and production. 

Cash Management - Controlling borrowing and cash 
flow within established guidelines. 

Financial Reporting and Analysis 

Compiling and analyzing financial data, determining 
trends, and recommending actions to be taken. 

Risk Management 

Determining areas of risk and obtaining coverage 
where needed. 

General Accounting 

The process of doing the day-by-day accounting work 

of the company. 

General Ledger - Maintaining records of original 
entry for all financial transactions of the company. 



Accounts Payable - Recording, verifying and 

satisfying obligations of the company. 

Fixed Asset Accounting - Maintaining records for 

security, production and tax needs. 

Payroll - Maintaining records and paying employees 

of the company according to established procedures. 

Credit and Billing - Authorizing credit, billing at 

established prices, recording payments, and effecting 

collections. 

Inventory Valuation - Physical counting of assets of 

the company, determining values, and recording 

differences. 

Overhead Allocation - Spreading fixed or common 

expenses by various methods appropriate to the 

particular item or location. 

Cost Accounting - Maintaining standard cost records 

of all products, recognizing variances, and recording 

them within established procedures. 
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Appendix G. Sample List of Wall Charts for Control Room 

Objectives of the Study • Products/Markets Data 

Scope of the Study • Map of the Distribution System 

Organization Chart - Business and Data Processing • Definitions of bsp Terminology 

List of Interviewees - Time and Day Schedule • Study Work Plan (Chart or Study Calendar) 

Names of the Study Team Members • Study Report Outline 

Business Goals and Objectives • Business Environment - External and Internal 

Data Processing Budget Information • Process/Organization Matrix 

Current Systems/Organization Matrix 

Current Systems/ Master Data File Matrix 
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Appendix H. Risk - Potential Benefit Analysis 



This technique attempts to quantify each perceived 
potential benefit. The textbook solution is to have the 
executive make a "ballpark" estimate of potential 
savings or gains. However, it is often difficult, though 
not impossible, to assign dollar savings to such areas as 
faster response time, tighter management control, and 
improved product performance. 

Assess potential values conservatively. Remember 
that estimates are useless unless the executive believes 
they are possible and really apply to his situation. 
When asking questions that will help the executive to 
make estimates: 

• Use a conservative guess, with a range of potential 
return of savings. 

• When at all doubtful, use figures the executive sees 
as absolute minimums. 

• When you refer to similar situations, be sure that 
they really are similar and that the executive can 
verify them. 

• Look for previous or currently existing data and 
statistics that indicate the range of potential return 
or savings. 

The team should focus on broad benefits to the 
point that they can be operationally defined. 

Probability prediction is a valuable tool, because it 
lends credibility to the estimates upon which justifica- 
tion is based. Use of the benefits matrix arrangement 
shown here may be particularly valuable in helping to 
assign approximate dollar values to benefits. 



High 
Probability 



Medium 
Probability 



Low 
Probability 



Displaced 
Costs 



Increased 
Productivity 



I ncreased 
Income 



Tl 


3l 


"61 


2I 


1\ 


81 ' 


4l 


71 


"9] 



The potential benefits matrix is used in the follow- 
ing manner: 

1. The potential benefits from each subsystem are 
totaled by the following categories: 
a. Displaced costs (increasing speed, reducing 
redundancy, etc.). Data processing has tradition- 
ally been evaluated in terms of cost displacement. 
This condition exists when a task, machine, 
supplies, or other expenses should no longer be 



required as a result of the new system. An exam- 
ple might be displacement of keypunch operators 
through remote data entry. 

b. Increased productivity (reducing widely varying 
workload, applying information to all areas of 
business, etc.). Another benefit accrues because 
the new system should allow existing or future 
facilities or people to do more work. This catego- 
ry may be viewed, therefore, as one of increased 
productivity and accuracy on the part of a clerical 
staff through online data entry. Future personnel 
requirements can potentially be held to a mini- 
mum. 

c. Increased income or revenue (automatic decision 
making, more data to aid decision, exception, 
reporting, etc.). This final category addresses the 
use of advanced computer applications to in- 
crease income. For example, freedom from 
routine decision making may enable management 
to spend more time on the really important 
decisions. Attainment of this benefit depends on 
business policy and the ability to effectively use 
the computer resource. 

In the example of production planning, the benefits 
estimated during the interviews with the vice president 
of production, the director of production planning and 
the manager of electronic sales might be: 
$1,000,000 - materials reduction 
300,000 - labor reductions 
600,000 - increased production 
500,000 - sales increase 
2. Using the estimated maximum potential savings, the 
team then estimates a dollar amount of that total 
possible return for which there is: 

a. High probability of realization 

b. Medium probability of realization 

c. Low probability of realization 

For instance, as shown in the following illustration, 
an automated production planning system might result 
in a toal materials saving of $1,000,000 annually but 
that total may not be immediate or certain. However, 
it is estimated that: 

a. There is a high, probability that raw materials 
may be reduced by $500,000. 

b. There is a moderate probability of an additional 
saving of $200,000 in finished goods inventory. 

c. While it isn't certain that the entire $ 1 ,000,000 
could be saved, it is possible. In this case, a 
further saving would result for an additional 
$300,000. 
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High Medium Low 

Probability Probability Probability 



Displaced 
Costs 



Increased 
Productivity 



Increased 
Income 



500,000 
100,000 

Tl 


200,000 

100,000 
31 


300,000 

100,000 
6l 


300,000 
2l 


200,000 
5l 


100,000 
8l 


200,000 
4l 


200,000 


100,000 
9l 



Materials 
reduction 

Labor 
reduction 

Increased 
production 



Profit 
increase 



Total 



1,100,000 700,000 



600,000 



3. This procedure is repeated for each I/S potential 
benefit for which there is high potential saving. 
Depending upon time available, estimates should be 
developed for all areas that could be quantified 
during the interviews. Totals are then developed in 
each category and for each subsystem. 





RISK LEVEL 




SUBSYSTEM 


1 


2 


3 


4 


5 


6 


7 


8 


9 


TOTAL 






















Production Planning 


600 


300 


300 


200 


200 


400 


200 


100 


100 


2,400 


Production Scheduling 






















Plant Status 






















Order Entry 






















Order Status 






















Sales Control 






















Cost 
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Product Data Control 






















Purchasing 
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Sales Analysis 






















Forecasting 






















Financial Modeling 






















Territory Analysis 






















Engineering Design 






















Skills Inventory 






















Compensation Administration 






















Financial Planning 























Notice that a number has been assigned to each cell 
of the matrix for illustration purposes only. These 
numbers show the likelihood that the potential benefit 
will happen. After the data has been collected, the 
team lists the dollar estimates for each system on the 
potential benefit level - risk level table shown. Each 
system is listed down the side of the table and the 
dollar amounts from each cell are entered in the 
correspondingly numbered column. 

The rows are then totaled. The completed table is a 
useful tool for summarizing in dollar terms the poten- 
tial benefits of the system the team recommends. The 
systems areas may now be compared (and/or ranked) 
on the basis of total (right-hand column) or any 
combination of risk levels (from left to right). 

Note: When recommending the first system for 
implementation, the study team should be alert to a 
potential problem. The most needed system may prove 
to be impractical to implement until another system is 
installed to furnish necessary input data. In such a 
case, management should be informed so that the 
reason for recommending a lower-priority system is 
understood. 
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Appendix I. ISM Processes 



Planning and Control 

Strategic Planning 
Assumptions Management 

Environmental analysis 

Tracking business objectives 

Human resource projections and skill requirements 

Technology direction 
Determining Policies 
Setting I/S Objectives 
Defining & Maintaining Information Architecture 

Business direction 

Information requirements 
Resource projections (installations, 
headcount and expense levels) 

Management Control 
Project and Resource Planning 

Long-range planning 

Capacity planning 

Justification and funding 

Short-range planning (projects, 

resources, organization, technologies, 

and skills) 

Budgeting 
Software, and Communication Facilities 

Monitor technological development 

Financial analysis 

Benchmark/testing 
Utilization Control 

Data usage 

Equipment usage 
, Communication facilities usage 

Functional modules usage 
Performance Measurement 

Budget performance 

Project phase reviews 

Quarterly project status reporting 

User satisfaction 

Application installation follow-up 

Security and recovery analysis 

Change status review 

Operations analysis 

Capacity status review 

Vendor performance 

Adherence to management practices 
Auditing 

Operations 

Project 

Management 



Data Administration 
Planning and Control 

Data planning 

Data acquisition 

Dictionary /directory management 

Standards management 

Documentation and training 

Plan measurement » 

Performance Control 

Physical design 

Modeling 

Performance evaluation 

Tuning 

Reorganization 
Usage Control 

Logical design 

Security, availability, auditability, artd 

integrity management 

Usage measurement 

Recovery 

Query 

Organization and Administration 
Manage the Organization Structure 
Define management practices (funding, 
project initiation, project control, auditing, 
justification, methods and standards, planning 
and budgeting, personnel, key measurements, 
data, and security) 
Manage Personnel 

Recruiting and hiring 

Career development 

Evaluation and productivity improvement 
Accounting 

Project accounting 

Chargeouts 

Recordkeeping 
Purchasing 
Used Equipment Sales 

Information Systems Development 

Requirements Definition 

Define subprocesses 
Define information requirements 
Determine objectives and control points 
Analyze cost/benefits 
Prepare design/development plan 
External Design 
External functions 
User inputs, output, data requirements 
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Depict systems flow and controls 

Data security 

Build test cases 
Internal Design 

Design internal modules 

Develop test plan 

Design walkthroughs 

Model systems performance 
Program Development 

Develop program specifications 

Code and test 

Integrate 
Systems Test 

Perform systems test 

Test user documentation 

Test documentation for operations and maintenance 

Test installation and conversion plan 

Test security 
Installation and Maintenance 

Train users 

Train operators 

Convert data 

Cutover 

Monitor reliability 

Post-installation audit 

Requirements analysis 

Change management 
Functional Modules 

Specify requirements 

Develop standards 

Make-or-buy decision 

Develop/purchase 

Install 

Dictionary /directory and library maintenance 

Audit 

Systems Management 

Capacity Management 

Define current system and load 
Forecast future workload 
Evaluate configurations/designs 
Track and analyze development 



Change Management 

Propose and document changes 

Plan/coordinate changes 

Implement changes 

Report, track and analyze changes 
Problem Management 

Report problems 

Monitor problems 

Resolve problems 

Analyze and prevent problems 
Operations Management 

Monitor/modify network, workload 

and configuration 

Schedule workload 

Operate/process 

Interface to users (problems 

and job requests) 
Recovery Management 

Determine recovery requirements 

Define recovery process 

Test and update recovery process 
Performance Management 

Set objectives 

Measure and analyze performance 

Modify /tune performance 
Security /Audit Management 

Assess current audit and security status 

Set requirements for authorizations, 

documentation and reconciliations 

Identify owners, users, and 

custodians of data 

Control I/O, error handling, and retention 

Provide physical security 

Monitor for compliance 
Executive Reporting 

Identify summary data 

Collect and analyze summary data 

Distribute reports/modification information 
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Appendix J. Potential Topics for BSP Study Report 



Executive Summary Report 

Purpose, scope and objectives 
Methodology and study team 
Summary of conclusions and recommendations 
Action plan for follow-on activities 

Detail Report 

Purpose, Scope and Objectives 

Reasons for conducting study 
Level of organization selected 
Objectives of the study team 
Method of Study 
BSP concepts 

Overview of study approach 
Study team members 
Business Perspective 
External environment 

Economic, government, competition 

Technology, customers, suppliers 
Internal environment 

Policies, practices, constraints 
Business planning 

Goals, objectives, strategies 

Planning approach and horizons 

Measurements and controls 
Organization 

Relationships (chart) 

Numbers of people 

Geographic distribution (map) 
Products/services 

Description, volume 

Markets, trends 

Industry position and industry trends 
Financial 

Statistics 

Revenue-profit trends (chart) 
Business processes 

Definition(s) 
Information Systems Pespective 
External environment 

Technology, customers (users), vendors 
Internal environment 

Policies, practices, constraints 
l/S planning 

Goals, objectives, strategies 

Resources, project schedules 

Planning approach and horizons 
Organization 

Relationships (chart) 

Numbers of people 



Geographic distribution (map of 

equipment, terminals, etc.) 
Information Systems Profile 

Hardware and software (chart) 

Operational and planned systems 

Data files 

Major users 
Financial 

Budgets 

Justification and funding processes 
Findings and Conclusions 
Definition of data classes 

Relationship of data class to current data 

files (matrix) 

Relationship of data class to business entity 

(matrix) 

Relationship of data class to business processes 

(matrix) 
Analysis of business/systems relationships 

Process relationships (diagram) 

Process/organization relationship (matrix) 

Application support/organization (matrix) 

Application support of processes (matrix) 

Relationship of applications to data class (matrix) 
Executive interview results 

Summary of major problems, solutions, and 

Information System needs (chart) 
Information Systems Management requirements 

Method used to determine ISM solutions 

and priorities 

Description of projects that address major 

ism problems 
Recommendations 

Information Systems Management 

Data management, l/S planning functions 

(additions/changes) 

Control and measurement procedures 

Requirements for a detailed Information Systems 

plan 
First system or subsystems 

Requirements for definition 
Information architecture 

Must be further defined - in particular, the 

databases 
Action Plan for Follow-On Projects 
(For the above recommendations) 

Description(s) 

Deliverables 

Schedules 

Resource requirements 

Project control methods 
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Appendices 

Glossary of terms 
Key correspondence 
Interviewee list and questions 



Narrative descriptions - processes 
Narrative descriptions - current applications/ 
systems 
Supporting statistics 
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Glossary 



Action plan - The group of activities, schedules, and 
resources recommended as a result of a BSP study (may 
be referred to as a general information systems plan). 
Application - A data processing activity providing 
information to one or more organizational units. 
Architectural priorities - The recommended sequence 
for implementation of the information architecture. 
Business - The organizational entity being studied, 
regardless of its size or purpose, either private or public 
sector. 

Business process - A group of logically related decisions 
and activities required to manage the resources of the 
business. 

Business Systems Planning - A structured approach to 
assist a business in establishing an information systems 
plan to satisfy its near- and long-term information 
needs. 

Control room - A work and interview room set aside 
for the continuous use of the team throughout the BSP 
study. 

Data class - A category of logically related informa- 
tion. Examples are customer, vendor, customer orders, 
parts inventory, and appropriations. 
Data base - A non-redundant collection of interrelated 
data items processable by one or more applications. 
Data file - An individual group of data related to or 
used by an existing application before implementation 
of a data base approach. 

External environment - Influences that exist outside the 
business being studied and over which the business has 
little or no control, e.g., government regulations, 
industry, competition, economy. 
Follow-on projects - Activities that occur after and as a 
result of the BSP study. 



Goal - A broad, general direction or intent. 
Information architecture - The structure of information 
systems and data that will provide information to 
support the business. 

Information system (i/S) - A logical group of subsys- 
tems and data required to support the information 
needs of one or more processes. 
Information systems management - Those functions 
required to manage the information systems resources 
for the most efficient and effective support of the 
business. 

Information systems plan - A plan that gives specific 
goals, strategies, project descriptions, resources, and 
schedules for the design, development, and implemen- 
tation of an information architecture. 
Objective - A specific and measurable item or element 
of a goal. 

Resource - That which is used or consumed by the 
business in the fulfillment of its objectives. 
Scope - The defined boundaries of the business being 
studied - divisions, function and geographic locations 
included and excluded. 

Sponsor - The executive who gives approval for the BSP 
study and to whom the team is responsible. 
Strategy - A planned action for achieving an objective. 
Team leader - The person who directs the study team, 
participates full time, and is responsible for the success 
of the study. 

Work plan - A plan that is developed to show activities, 
responsibilities and schedules for the work to be 
performed during the BSP study. 
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